Après que l'IA écrit l'application : pouvez-vous relire le diff et merger ?

La conclusion d’abord : quand l’IA peut écrire n’importe quel code, « écrire vite » cesse d’être un avantage — tout le monde en est capable. Ce qui devient vraiment rare, c’est votre courage de cliquer sur ce bouton Merge. Et ce courage dépend d’une chose : ce que l’IA vous remet est-il quelque chose que vous pouvez réviser, gouverner et assumer ?

Commençons par une scène qui se joue déjà tous les jours.

Une ingénieure demande à son agent de codage de « me bricoler une petite appli de remboursement pour le support client ». Une demi-heure plus tard, une application fonctionnelle apparaît : front-end, API, migrations de base de données, tests — tout y est, CI tout au vert. Elle ouvre la PR et voit une ligne : +8 142 −0.

Et là, elle se bloque.

Ces huit mille lignes, ce n’est pas elle qui les a écrites ; elle n’en a pas lu une seule. Où se trouve la validation du plafond du montant remboursé ? Cette API renvoie-t-elle aussi les remboursements d’autres clients ? La modifier va-t-il casser le rapprochement comptable au passage ? Elle n’en sait rien — parce que personne n’en sait rien. Un CI vert prouve seulement que « le code tourne sans se contredire » ; il ne prouve pas qu’« il fait la bonne chose, et seulement ce qui est autorisé ».

Elle a deux options, toutes deux mauvaises : soit elle prend sur elle, fait comme si elle avait revu le code et clique sur Merge — mettant en production une boîte noire que personne ne comprend ; soit elle lit vraiment ces huit mille lignes, ligne par ligne — auquel cas autant les avoir écrites elle-même. Voilà le vrai nouveau goulot d’étranglement de l’ère de l’IA : ce n’est pas écrire le code, c’est cliquer sur Merge.

Écrire du code est devenu une commodité, pas la « confiance »

Ces dix dernières années, la compétence rare de l’ingénieur, c’était « savoir le construire ». Cette compétence, l’IA est en train de l’aplanir, vite et complètement. Quand le coût marginal de générer une application tend vers zéro, « vite » n’est plus le rempart de personne — l’agent de votre concurrent va tout aussi vite.

Ce qui passe alors au premier plan, c’est une autre chose, toujours présente mais jusqu’ici masquée par le coût d’écrire le code : quelqu’un doit répondre de ce code. Quelqu’un doit pouvoir répondre à « quelles données a-t-il lues, quelles actions peut-il faire, à qui la faute en cas d’erreur, est-ce traçable dans l’audit ». Une fois que l’IA a ramené à zéro le coût d’« écrire », « réviser et gouverner » devient le maillon le plus cher et le plus critique de tout le processus. La révisabilité est le nouveau rempart de l’ère où l’IA écrit le code — il ne s’agit pas de qui génère le plus, mais de qui ose mettre en production ce qu’il a généré.

C’est exactement l’autre face de ce que racontaient la dette technique du vibe coding et les pilotes d’agents IA qui échouent avant la production : le vibe coding permet à tout le monde de générer des applis, mais une fois générées, personne n’ose les mettre en production — parce que personne ne peut les réviser ni s’en porter garant. La seule différence : ces deux articles adoptaient le point de vue de l’entreprise et des décideurs ; celui-ci adopte le vôtre — celui de la personne dont le doigt est suspendu au-dessus du bouton Merge.

Pourquoi « laisser une autre IA réviser » ne boucle pas la boucle

La parade la plus naturelle : puisque l’IA sait écrire, laissons une IA faire la review, non ? Les agents de revue de code, les scans de sécurité automatiques, ça existe déjà.

Cette voie arrête une partie des problèmes, mais elle ne boucle pas la boucle vraiment critique.

Revenons à ce GET /api/refunds. Il renvoyait les remboursements de tout le monde — et pourtant il passe la quasi-totalité des contrôles automatiques : pas d’erreur de syntaxe, pas de pointeur nul, des tests (écrits par le même agent, qui n’a donc testé que « on retrouve bien les remboursements », jamais « a-t-on le droit de retrouver ceux des autres »). Ce que la revue par IA fait bien, c’est vérifier si le code est correct vis-à-vis de lui-même : y a-t-il des bugs, respecte-t-il les patterns de vulnérabilité connus, le style est-il cohérent. Elle ne peut pas répondre à trois questions qui se situent en dehors du code : ce code devrait-il lire cette table ? Cette action devrait-elle toucher à cet argent ? Est-ce bien la règle métier que nous voulons ?

Ces réponses ne sont pas dans le code — elles sont dans le modèle de permissions, dans la politique d’approbation, dans l’intention métier. Deux IA qui se font signe de la tête, ce n’est pas de la gouvernance. Cette réponse à « qui a autorisé, qui répond » que réclament l’auditeur, le juridique et l’équipe sécurité, aucun modèle de revue, aussi brillant soit-il, ne peut la signer. Donc « faire réviser l’IA par l’IA » économise l’effort humain de lire le code, mais pas ce jugement du « devrait-on ou non » qui doit obligatoirement être porté par un humain. Et le problème revient à son point de départ : l’humain doit pouvoir réviser. Or huit mille lignes, l’humain n’en vient pas à bout.

La voie de sortie : réduire ce que l’IA vous remet à quelque chose que vous pouvez réviser

Le fait que vous ne veniez pas à bout de huit mille lignes, et le fait que ce système pourrira dans six mois, ont la même cause — personne ne comprend vraiment ce paquet d’implémentation (c’est ce que cet article appelait la « dette de compréhension »).

Alors changeons la forme de ce que l’IA livre : ne lui faites pas générer l’implémentation, faites-lui générer la déclaration. Pour cette même appli de remboursement, ce que l’IA devrait vous remettre, ce n’est pas huit mille lignes de code, mais un diff de métadonnées comme celui-ci :

+ object: support_refund
+   amount: currency (min 0)
+ permission: support_agent
-   allowDelete: true        # la première version générée par l'agent en donnait trop
+   allowDelete: false       # retiré à la révision : le support ne peut pas supprimer un remboursement
+ flow: refund_amount > 500 → approbation finance requise

Cette dizaine de lignes, vous pouvez la lire ligne par ligne, la réviser en cinq minutes, l’annuler d’un clic. Plus important encore, les dernières lignes : réviser n’est plus « est-ce que j’arrive au bout de ma lecture » mais devient « cette permission est-elle correcte, ce seuil d’approbation est-il raisonnable » — une question métier que vous pouvez vraiment trancher, et qu’il vous revient de trancher. Ce GET /api/refunds qui fuyait ne peut tout simplement pas apparaître ici : le droit de lecture de support_refund est déclaré « selon les permissions de l’appelant », le runtime l’impose en conséquence, et la voie de l’élévation de privilège est fermée à la source.

Et l’implémentation, où est-elle passée ? L’implémentation appartient à un runtime audité encore et encore, partagé par toutes les applications (ObjectOS) ; elle n’est pas régénérée pour chaque appli. Le « devrait-on » — peut-on lire, peut-on supprimer, faut-il une approbation — est imposé par le runtime au moment de l’exécution, et non enfoui dans huit mille lignes au petit bonheur.

Une boucle qui se referme vraiment

Schématisée en un flux, cette démarche est une boucle où un humain est toujours présent, mais sans jamais se noyer sous le volume de code :

Remarquez l’étape ④ : parce que la définition métier déclare elle-même les objets et les permissions, le runtime la projette en un ensemble d’outils gouvernés — si bien que le même agent n’a pas seulement « écrit » cette appli, il peut ensuite l’exploiter dans les mêmes limites de permissions (consulter des remboursements, en déclencher), chaque étape portant une identité et laissant une trace. Écrire et utiliser partagent une seule et même gouvernance.

D’abord, une douche froide

Cette approche a ses limites, autant le dire clairement.

Premièrement, tout ne peut pas devenir des métadonnées. Un nouvel algorithme temps réel, un pipeline de rendu unique, requièrent encore du vrai code, et il faudra encore que quelqu’un prenne sur lui pour faire la review de cette partie — les métadonnées ne vous aideront pas, et vouloir les y forcer ne ferait qu’empirer les choses. Ce qu’elles font bien, ce sont les systèmes métier répétitifs que les entreprises reconstruisent sans cesse : objets, vues, permissions, workflows, approbations.

Deuxièmement, la confiance est déplacée, pas supprimée. Vous ne révisez plus l’implémentation de chaque appli une par une, mais vous misez votre confiance sur ce runtime — il doit être audité sérieusement une fois, et maintenu en continu. Mais faites le calcul : dans l’approche traditionnelle, chaque appli que l’IA génère vous oblige à refaire confiance à un nouveau paquet de code ; dans l’approche par métadonnées, vous auditez le runtime une fois, et chaque appli qu’il dérive ensuite hérite automatiquement du même jeu de permissions et d’audit déjà validé. Auditer une fois vaut mieux qu’auditer mille fois. C’est une bien meilleure affaire, mais c’est une affaire, pas de la magie.

Conclusion

Le fait que l’IA sache écrire du code ne mettra pas les ingénieurs au chômage, mais déplacera le poste de garde le plus crucial de l’ingénieur : de « est-ce que je sais l’écrire » à « est-ce que j’ose signer pour ce que l’IA a écrit ».

Et votre courage de signer dépend presque entièrement de ce que l’IA pose devant vous — huit mille lignes d’implémentation dont vous ne viendrez pas à bout, ou quelques dizaines de lignes de déclaration que vous pouvez réviser et que le runtime peut gouverner. Ne demandez pas à votre agent d’écrire un tas de code ; demandez-lui de générer une cible que vous pouvez réviser et que le runtime peut soutenir.

npm i -g @objectstack/cli && os start

Pointez votre agent de codage vers une cible déclarative et gouvernable, plutôt que de lui lancer « écris-moi un CRUD » — puis regardez le diff de la prochaine PR : est-il enfin assez petit pour que vous osiez cliquer sur Merge.