Le code est écrit par l’IA, mais votre infrastructure peut-elle suivre ?

Nous vivons une des inversions les plus étranges de l’histoire de l’ingénierie logicielle. Pendant des décennies, l’objectif était la déterminisme ; construire des systèmes qui se comportent de la même manière à chaque fois. Maintenant, nous superposons des agents d’IA probabilistes à cette fondation, générant du code à une échelle et une vitesse alarmantes. Et honnêtement ? La plupart de nos infrastructures n’ont pas été conçues pour cela.

J’ai passé des années à travailler sur les outils DevOps, à co-écrire des recherches et à aider les équipes d’ingénieurs à atteindre leur meilleur niveau de performance. Ce que je vois maintenant avec le développement piloté par l’IA est plus qu’une évolution. C’est l’exposition de chaque faille dans nos flux de travail existants.

Le problème est déjà là

Une étude GitClear de 2025 a constaté que près de 7 % des validations contiennent maintenant du code généré par l’IA. Leur analyse précédente de 153 millions de lignes de code modifié a révélé le coût : le « churn de code » – le code réécrit ou supprimé dans les deux semaines – a doublé d’ici 2024 par rapport aux références pré-IA.

Les implications en matière de sécurité sont tout aussi alarmantes. Une analyse récente de 80 tâches de codage ciblées sur plus de 100 grands modèles de langage a constaté que le code généré par l’IA introduit des vulnérabilités de sécurité dans 45 % des cas. L’impact réel ? Un CISO sur cinq signale maintenant des incidents majeurs directement causés par le code généré par l’IA.

Les gains de vitesse sont réels, mais les coûts de stabilité sont également réels.

L’effet d’amplification

Une chose que j’ai apprise, c’est que l’IA amplifie tout. Si vous avez de bonnes pratiques, l’IA les améliore et les accélère. Si vos processus sont désorganisés, l’IA aggrave le désordre. Cela reflète un modèle qui apparaît année après année dans les rapports DevOps de DORA : moins de variables conduisent à de meilleurs résultats. Les équipes réussies standardisent sur moins de systèmes d’exploitation, moins de langages de programmation, moins de façons de faire les choses. Ils réduisent la complexité délibérément.

Les agents d’IA suivent le même modèle. Lorsque vous leur donnez un environnement cohérent où Python signifie la même version sur chaque machine de développeur, où les dépendances sont verrouillées et suivies, ils excellent. Lorsque vous les forcez à naviguer dans 17 configurations différentes, chacune avec des différences subtiles, vous brûlez des jetons pour comprendre les particularités de l’environnement au lieu de résoudre les problèmes réels.

La paradoxe de la déterminisme

Cela crée une tension fascinante. Pendant des années, l’informatique a poursuivi la déterminisme comme objectif ultime. Maintenant, nous exécutons des charges de travail probabilistes, des modèles d’IA qui ne peuvent littéralement pas garantir la même sortie deux fois, sur des systèmes conçus pour la prévisibilité.

Ma réponse ? Garder autant que possible de la pile déterministe. Si vous pouvez maintenir 80 % de votre infrastructure à un niveau déterministe, vos agents d’IA ont moins de variables à gérer. Ils ne passent pas de fenêtres de contexte à « Pourquoi cette dépendance n’a-t-elle pas été installée ? » ou « Laissez-moi essayer cette commande de build à nouveau ». Ils se concentrent sur le travail réel que vous leur demandez de faire.

Pensez-y : lorsque un agent tente de compiler quelque chose et que les liaisons natives échouent parce que ImageMagick n’est pas installé, c’est un détour coûteux en jetons. Si votre environnement contient déjà tout ce qui est nécessaire (compilateurs, bibliothèques, l’arbre de dépendances complet jusqu’à libc), l’agent fonctionne simplement. Aucun débogage, aucune erreur, juste progrès.

La spécification et la validation sont clés

Ce qui devient clair, c’est que le développement piloté par l’IA nous oblige à réfléchir plus dur aux deux compétences historiquement sous-estimées : la spécification et la validation. Vous devez articuler ce que vous construisez réellement et vous devez avoir des méthodes robustes pour vérifier que vous l’avez obtenu.

J’ai remarqué quelque chose d’intéressant : les personnes ayant une formation en gestion de produits ou en ingénierie de produits sont souvent plus réussies avec les agents d’IA pour le moment. Ils sont déjà formés pour réfléchir en termes d’exigences, de critères de réussite et de compromis. Ils sont à l’aise pour demander « Pourquoi avez-vous fait ce choix ? » et ajuster en fonction du raisonnement.

La validation, savoir si la chose est réellement correcte, a toujours été le problème le plus difficile de l’ingénierie logicielle. La QA a été sous-estimée pendant des décennies, et pourtant c’est la partie la plus difficile : déterminer si le logiciel résout réellement le besoin de l’utilisateur. L’IA ne résout pas ce problème. Si quoi que ce soit, elle le rend plus critique, car maintenant vous validez des sorties probabilistes par rapport à des exigences déterministes.

Faites confiance, mais vérifiez (et contrôlez)

Il y a un sentiment que j’adopte de plus en plus : nous devrions supposer que le code généré par l’IA est hostile jusqu’à preuve du contraire. Non pas parce que l’IA est malveillante, mais parce que nous ne savons simplement pas. Nous ne pouvons pas auditer chaque ligne lorsque les agents génèrent des milliers de lignes par jour.

Cela signifie déplacer les points de contrôle. Si nous ne pouvons pas tout contrôler au moment du développement, nous avons besoin de contrôles plus solides au moment de l’exécution. Les opérateurs, les SRE, les équipes de plate-forme, qui que ce soit qui est responsable de la production, ont besoin d’une meilleure visibilité sur ce qui s’exécute, d’un suivi complet des dépendances et d’une provenance claire pour chaque artifact.

C’est là que la reproductibilité devient essentielle. Lorsque vous pouvez prouver mathématiquement que l’artifact que vous avez testé localement est identique à ce qui s’exécute en production – mêmes entrées, mêmes sorties, même fermeture des dépendances – vous pouvez commencer à prendre des décisions intelligentes. Peut-être n’avez-vous pas besoin de réexécuter les tests d’unités dans le CI si vous les avez déjà exécutés localement et que rien n’a changé. Peut-être pouvez-vous mapper la couverture des tests aux modifications de code et ignorer les suites de tests non pertinentes.

Ce qui vient ensuite

Nous sommes à un point d’inflexion. Les équipes qui avaient déjà de bonnes pratiques voient des gains de productivité massifs avec l’IA. Les équipes qui luttaient sont maintenant en difficulté plus rapidement.

L’infrastructure qui alimente le développement piloté par l’IA doit être conçue pour la reproductibilité dès le départ. Non pas greffée après coup avec des outils de scan et des audits, mais intégrée à la façon dont les développeurs travaillent dès le premier jour. Lorsque votre environnement de développement est identique sur Mac et Linux, lorsque chaque dépendance est suivie et verrouillée, lorsque vous avez une provenance complète pour chaque artifact, les agents d’IA deviennent des multiplicateurs de force au lieu de générateurs de chaos.

Voici mon plus grand conseil pour les équipes qui tentent de réussir à l’ère de l’IA :

• Standardisez sans pitié. Moins de variables correspondent à de meilleures performances. Verrouillez votre pile technologique, imposez des environnements cohérents sur toutes les plateformes et éliminez les dérives de configuration avant que l’IA ne les amplifie. Si les incompatibilités de version Python causent des problèmes maintenant, elles causeront 10 fois plus de problèmes lorsque l’IA générera du code à grande échelle.

• Intégrez la validation dans votre flux de travail, et non à la fin. Avec l’IA générant du code plus rapidement que les humains ne peuvent le revoir, vous ne pouvez pas vous fier uniquement à la revue de code manuelle. Mettez en œuvre des tests automatisés qui valident non seulement que le code s’exécute, mais qu’il résout réellement l’exigence. Faites de votre pipeline CI/CD votre filet de sécurité, avec des portes solides au moment de l’exécution pour les déploiements de production.

• Investissez dans la reproductibilité en tant qu’infrastructure. Traitez la cohérence de l’environnement comme une préoccupation d’infrastructure de premier plan. Lorsque vous pouvez prouver mathématiquement que votre environnement local, votre environnement CI et votre environnement de production sont identiques, vous éliminez une classe entière de problèmes de type « ça marche sur ma machine ». Cette fondation déterministe est ce qui vous permet de superposer en toute sécurité des charges de travail d’IA probabilistes.

La question n’est pas de savoir si l’IA écrira la plupart de notre code. Elle le fait déjà pour de nombreuses équipes. La question est de savoir si notre infrastructure peut suivre.