L’IA écrit le code. Mais qui vérifie qu’elle n’a rien cassé ?

Tout fonctionne. Jusqu'au moment où quelqu'un essaie autre chose.

Imaginez une application de réservation.

Vous demandez à un agent IA d'ajouter une nouvelle fonctionnalité : permettre aux utilisateurs de modifier leur réservation après avoir payé.

Quelques minutes plus tard, la fonctionnalité apparaît.

Le bouton fonctionne. La page s'affiche correctement. Le système confirme la modification.

Démonstration réussie.

Mais que se passe-t-il si deux personnes essaient de réserver le même créneau ? Si le paiement échoue au milieu de l'opération ? Si un utilisateur tente de modifier la réservation d'une autre personne ?

Et la fonctionnalité précédente, fonctionne-t-elle toujours ?

Cet exemple est fictif. Mais il illustre une difficulté fondamentale du développement logiciel : ce qu'une application montre à l'écran ne suffit pas à démontrer qu'elle fonctionne correctement dans toutes les situations pertinentes.

C'est précisément à cet endroit que la révolution de l'IA commence à changer de nature.

Pendant longtemps, la question était de savoir si une intelligence artificielle pouvait écrire du code.

Elle le peut.

La question devient maintenant beaucoup plus exigeante : comment contrôler tout ce qu'elle produit, et comment détecter les erreurs qu'elle peut introduire dans un logiciel existant ?

En un an, le « vibe coding » a changé de signification

En février 2025, Andrej Karpathy, ancien responsable de l'IA chez Tesla et cofondateur d'OpenAI, popularise une expression : vibe coding.

L'idée est volontairement déconcertante.

Au lieu de programmer chaque fonction, on explique à une IA ce que l'on souhaite obtenir, puis on accepte ses propositions, parfois sans examiner précisément le code généré.

Ce mode de création ouvre une possibilité spectaculaire : transformer une intuition en prototype sans maîtriser toute la complexité technique sous-jacente.

Mais il comporte une faiblesse évidente.

Si l'on ne comprend pas ce que l'IA a construit, comment savoir ce qu'elle a réellement changé ?

Le 20 avril 2026, lors de l'événement AI Ascent organisé par Sequoia Capital à San Francisco, Andrej Karpathy revient sur cette évolution dans un échange avec Stephanie Zhan. La vidéo de cette conversation est publiée le 29 avril.

Le titre de l'entretien résume le changement : From Vibe Coding to Agentic Engineering.

Ce n'est pas simplement une nouvelle expression à la mode.

Le passage du vibe coding à l'ingénierie agentique traduit une évolution des pratiques : l'IA ne sert plus uniquement à improviser du code, elle devient un exécutant puissant à l'intérieur d'un processus d'ingénierie.

La distinction est essentielle.

Avec le vibe coding, la réussite peut se mesurer à une question simple : est-ce que le résultat semble fonctionner ?

Avec l'agentic engineering, cette question devient insuffisante.

Il faut pouvoir expliquer ce qui a été demandé, ce qui a changé, quels contrôles ont été réalisés et quelles limites demeurent.

Le premier produit du code. Le second cherche à produire un résultat vérifiable.

Cette différence ne dépend pas nécessairement de l'outil choisi. Un même agent peut être utilisé de manière improvisée ou dans un processus très encadré.

Google décrit le déplacement du véritable travail

En 2026, Google publie The New SDLC With Vibe Coding, un livre blanc rédigé par Addy Osmani, Shubham Saboo et Sokratis Kartakis.

Le document, daté de mai et présenté publiquement en juin, analyse la transformation du cycle de développement logiciel sous l'effet des agents IA.

Son constat central est particulièrement intéressant.

L'intelligence artificielle réduit fortement l'effort nécessaire pour produire une première implémentation. Mais les autres étapes du développement ne disparaissent pas à la même vitesse.

Comprendre un besoin. Choisir une architecture. Définir des règles métier. Vérifier le comportement. Arbitrer les risques.

Ces activités nécessitent toujours du jugement.

Le développeur ne passe donc pas simplement moins de temps devant son clavier.

Le centre de gravité de son métier se déplace de l'écriture vers la spécification et la vérification.

Prenons un exemple.

Demander à une IA de créer un formulaire de connexion peut produire rapidement une interface convaincante.

Mais le véritable besoin est plus large.

Le système doit-il autoriser plusieurs appareils ? Comment récupère-t-on un compte ? Que se passe-t-il après plusieurs tentatives infructueuses ? Quelles données peut consulter chaque catégorie d'utilisateur ?

Ces décisions ne peuvent pas être remplacées par une interface élégante.

Elles doivent être explicitées, documentées et traduites en comportements que l'on pourra vérifier.

Cela conduit à une idée contre-intuitive.

À mesure que le code devient plus facile à produire, définir précisément ce que le logiciel doit faire devient encore plus important.

La vraie révolution : demander des preuves plutôt que des promesses

Une organisation qui utilise des agents IA de façon structurée ne se contente pas de leur demander de créer une fonctionnalité.

Elle leur fournit des objectifs, des contraintes et des critères de réussite.

La différence se joue avant même la première ligne de code.

D'abord, il faut définir le comportement attendu.

Une fonctionnalité ne doit pas seulement être décrite par son apparence, mais aussi par les règles qu'elle doit respecter.

Ensuite, l'agent doit comprendre le contexte du projet.

Quels composants existent déjà ? Quelles conventions sont utilisées ? Quelles parties du système ne doivent pas être modifiées ? Quels contrôles de sécurité sont indispensables ?

Vient alors l'implémentation.

L'agent peut modifier plusieurs fichiers, proposer une solution et exécuter les outils auxquels il a accès.

Mais son travail ne s'arrête pas lorsque le code a été produit.

Des tests unitaires vérifient certains comportements isolés. Des tests d'intégration contrôlent les interactions entre composants. Des tests de régression cherchent à détecter les fonctionnalités existantes que la modification aurait détériorées.

Une revue des changements permet ensuite d'examiner ce qui a réellement été ajouté, supprimé ou transformé.

Enfin, une décision doit être prise : les résultats constituent-ils une preuve suffisante pour accepter la modification ?

Cette chaîne n'a rien de nouveau dans son principe.

L'ingénierie logicielle utilise depuis longtemps des spécifications, des tests, des revues de code et des procédures de déploiement.

Ce qui change, c'est la place occupée par l'IA dans chacune de ces étapes.

L'agent peut désormais écrire du code, préparer des tests, exécuter des vérifications et corriger certains problèmes détectés.

L'humain, lui, doit s'assurer que les critères de réussite sont pertinents et que les contrôles couvrent réellement les risques.

Anthropic décrit précisément cette logique dans un article publié le 22 juillet 2026 consacré aux boucles de vérification de Claude Code.

Le principe consiste à permettre à l'agent d'observer les résultats de ses propres actions, d'identifier certains échecs puis de reprendre son travail.

Au lieu de demander uniquement une fonctionnalité, on construit un cycle : produire, contrôler, corriger et recommencer.

Ce fonctionnement peut améliorer la discipline du développement.

Il ne rend pourtant pas les erreurs impossibles.

Un test réussi ne signifie pas que tout est correct

C'est l'une des limites les plus importantes à comprendre.

Un test vérifie un comportement défini à l'avance.

S'il ne couvre pas une situation, il ne peut pas garantir que cette situation est correctement traitée.

Imaginons qu'une IA modifie un mécanisme d'authentification.

Les tests existants peuvent confirmer qu'un utilisateur parvient toujours à se connecter.

Mais ils ne détecteront pas nécessairement une nouvelle possibilité d'accès non autorisé si aucun test n'examine ce scénario.

Le problème n'est pas seulement la qualité du code.

Il peut se trouver dans les exigences elles-mêmes, dans un test incomplet ou dans une hypothèse que personne n'a remise en question.

C'est pourquoi les outils d'analyse automatique constituent des protections utiles, mais pas une certification absolue.

Le 9 juin 2026, GitHub annonce la disponibilité générale de contrôles de sécurité automatiques pour les agents de programmation tiers, notamment Claude et Codex, dans les configurations concernées.

La plateforme décrit trois mécanismes : l'analyse de vulnérabilités avec CodeQL, la vérification des dépendances nouvellement introduites à partir de sa base d'avis de sécurité et la recherche de secrets exposés.

Lorsqu'un problème est identifié, l'agent peut tenter de le corriger avant de finaliser sa proposition de modification.

C'est un changement concret.

La sécurité n'est plus uniquement une étape que l'on réalise manuellement après la production du code. Certains contrôles peuvent être intégrés au travail de l'agent.

Mais aucun de ces mécanismes ne démontre qu'un programme est exempt de défauts.

Un logiciel peut réussir ses tests tout en répondant mal au besoin initial.

Il peut respecter les règles de syntaxe tout en comportant une erreur de conception.

Il peut ne présenter aucune vulnérabilité connue détectée par les outils employés tout en exposant un risque qui n'a pas été recherché.

L'objectif n'est pas d'obtenir un voyant vert. C'est de savoir précisément ce que ce voyant permet de conclure.

Cette nuance devient décisive lorsque des agents produisent des volumes croissants de code.

Plus il est facile de modifier un système, plus il devient nécessaire de maîtriser les conséquences de ces modifications.

Et si écrire plus vite ne faisait pas toujours gagner du temps ?

L'intelligence artificielle impressionne par la rapidité avec laquelle elle peut produire du code.

Mais la vitesse de génération n'est pas synonyme de productivité réelle.

Il faut aussi compter le temps passé à expliquer le besoin, comprendre la solution, examiner les modifications, corriger les erreurs et vérifier l'ensemble.

Une étude publiée en juillet 2025 par l'organisme de recherche METR avait produit un résultat surprenant.

Dans cet essai randomisé portant sur 16 développeurs et 246 tâches, les travaux réalisés avec autorisation d'utiliser l'IA ont nécessité en moyenne 19 % de temps supplémentaire par rapport aux tâches sans IA. L'intervalle de confiance allait de +2 % à +39 %. Ce résultat concerne les outils et les conditions étudiés au premier semestre 2025.

Cela ne signifie pas que l'IA ralentit tous les développeurs.

Le résultat concernait des personnes expérimentées, des projets existants et les outils disponibles au premier semestre 2025.

En février 2026, METR publie une nouvelle analyse indiquant que les outils plus récents pourraient procurer davantage de gains.

Mais les chercheurs soulignent que des biais de participation et des difficultés de mesure empêchent de quantifier solidement cette accélération dans leur nouvelle expérience.

Ces travaux illustrent une réalité importante : les gains dépendent fortement du contexte, des outils, des tâches et du coût des vérifications.

Un agent peut produire une modification en quelques minutes.

Si une équipe doit ensuite consacrer plusieurs heures à comprendre ses conséquences, le bénéfice devient beaucoup moins évident.

À l'inverse, une tâche bien délimitée, accompagnée de tests fiables et de règles explicites, peut se prêter beaucoup mieux à l'automatisation.

La question pertinente n'est donc pas : combien de lignes de code l'IA a-t-elle écrites ?

Elle devient : combien de travail utile, fiable et accepté a-t-elle réellement permis d'accomplir ?

Le développeur devient-il un chef d'orchestre ?

L'essor des agents ne signifie pas que le métier de développeur disparaît.

Il modifie néanmoins la répartition des tâches.

Certaines activités auparavant réalisées directement par une personne peuvent être confiées à une IA : explorer une base de code, proposer une modification, écrire un premier jeu de tests ou préparer une documentation.

Le développeur doit alors consacrer davantage d'attention à la compréhension globale du système.

Il lui revient notamment de déterminer quelles parties peuvent évoluer, quelles dépendances doivent être préservées et quels risques justifient un contrôle humain renforcé.

Cette transformation ne concerne pas uniquement les ingénieurs expérimentés.

Elle peut aussi modifier la manière dont les débutants apprennent.

Savoir obtenir du code devient plus facile.

Comprendre pourquoi ce code fonctionne, identifier ses limites et raisonner sur ses conséquences reste indispensable pour pouvoir en assumer la responsabilité.

La compétence technique ne disparaît donc pas.

Elle change partiellement de forme.

Le spécialiste qui écrivait lui-même chaque modification peut devenir celui qui prépare les conditions dans lesquelles plusieurs agents travaillent, vérifie leurs résultats et décide ce qui doit être conservé.

Mais cette évolution n'est ni uniforme ni automatique.

Certains projets nécessiteront encore beaucoup de programmation directe. D'autres se prêteront davantage à l'orchestration d'agents.

Tout dépendra de la complexité du produit, du niveau de risque, de la qualité des outils et de la capacité des équipes à comprendre leurs propres systèmes.

Le danger serait de confondre délégation et maîtrise.

Un ingénieur qui ne comprend plus l'architecture de son produit risque de perdre précisément la capacité nécessaire pour juger les décisions proposées par ses agents.

Déléguer l'écriture du code ne signifie pas déléguer la compréhension du logiciel.

La nouvelle frontière n'est plus le bouton « Générer »

Pendant longtemps, les démonstrations d'IA appliquée au développement logiciel ont cherché à prouver une capacité.

Créer un site en quelques minutes.

Construire une application à partir d'une description.

Transformer une conversation en logiciel fonctionnel.

Ces démonstrations restent impressionnantes.

Mais elles ne suffisent plus à caractériser la maturité d'une pratique d'ingénierie.

La véritable frontière se situe désormais entre deux situations.

D'un côté, un utilisateur demande quelque chose, observe un résultat convaincant et décide de lui faire confiance.

De l'autre, une équipe formule des exigences, laisse les agents proposer des solutions, vérifie les preuves disponibles et accepte ou refuse les changements selon des critères explicites.

La seconde démarche est moins spectaculaire à montrer dans une vidéo.

Elle peut pourtant être beaucoup plus importante pour construire des logiciels destinés à durer.

Ce n'est pas un hasard si les acteurs du secteur développent des dispositifs de revue, de validation, de sécurité et de contrôle autour de leurs agents.

La génération de code devient une capacité de base.

La différenciation se déplace vers la qualité des instructions, la compréhension du contexte, la capacité de vérification et la fiabilité du processus.

Le vibe coding n'a donc pas disparu.

Il conserve une utilité pour explorer une idée, tester une interface ou construire un prototype dont les conséquences sont limitées.

Mais lorsqu'un logiciel doit servir de véritables utilisateurs, manipuler des données sensibles ou fonctionner avec des systèmes existants, improviser ne suffit plus.

Il faut pouvoir comprendre ce qui a été construit et établir pourquoi on accepte de le mettre en service.

Demain, le meilleur développeur ne sera pas nécessairement celui qui écrit le plus de code. Ce pourrait être celui qui sait le mieux définir ce qui doit fonctionner — et refuser ce qui n'est pas suffisamment vérifié.