Les échelles de niveaux d'autonomie de l'IA se multiplient depuis deux ans, et elles se ressemblent toutes. L'une des premières, celle de Dan Shapiro, va du code écrit à la main jusqu'à la « software factory », où plus aucun humain ne touche au code. La première fois que je l'ai lue, je me suis placé au niveau 3 en trente secondes, celui que Dan résume par « your life is diffs ». L'agent produit la fonctionnalité, les tests et la PR, et je passe mes journées à relire ce qu'il a fait. Ce qui m'a pris plus de temps à digérer, c'est le barreau suivant. Au niveau 4, on écrit la spécification, on laisse l'agent travailler, et on vérifie seulement que les tests passent. On ne lit plus le code qu'on livre. Honnêtement, je trouvais ça un peu fou. Je passe mes journées avec des agents, et je vois encore les absurdités dont ils sont capables, même gavés d'instructions et de garde-fous.
Pour que ce soit clair dès le départ, j'utilise ces outils tous les jours et je ne reviendrai pas en arrière. La question qui me travaille n'est pas si on délègue à la machine. C'est à quel point, et sur quoi?
Une échelle comme celle-là n'a pas le même usage selon qui la lit. Un gestionnaire y cherche une carte : où se situe l'organisation, où elle pourrait aller. Pier-Luc Rodrigue, vice-président et directeur général de Nexapp, en a tracé une dans Deux ans d'IA chez Nexapp, inspirée de celle de Dan. Pier-Luc y parle de niveaux. Depuis, on a commencé à les appeler des modes agentiques. Le développeur ou la développeuse qui vit cette échelle au quotidien y cherche une réponse plus courte : comment je travaille sur la tâche que je commence ce matin? C'est de cette question que je pars ici.
Partout, arrêter de lire le code est présenté comme le vrai saut à faire. Le message que ça envoie, qu'on le veuille ou non, c'est que si je prends le temps de tout relire, je suis en retard sur quelque chose. C'est ce malaise qui a lancé cet article. Relire tout ce que je livre, est-ce un retard... ou un choix?
Sur ces échelles, un barreau se démarque des autres. Jusqu'au mode 3, je relis le code que l'IA a produit avant de le livrer. Au mode 4, je valide. Je ne lis plus le code, je vérifie seulement que les tests passent et que la fonctionnalité fait ce qu'on voulait. C'est là que ça devient radical. On passe de tout lire à ne plus rien lire.
Une fois le saut nommé, mon malaise devenait une question vérifiable. Si refuser ce saut est un retard, il me manque soit de l'outillage, soit de la confiance. Vérifions les deux.
Laissez-moi décrire une tâche normale dans mon quotidien. Je travaille sur des solutions d'entreprise de grande envergure, des systèmes qui doivent toujours fonctionner, être réparables rapidement, et qui vont m'occuper pendant des années.
Avant de coder, je génère un plan d'architecture avec l'IA, je le review, je le challenge, puis je valide avec mes pairs. Une série de skills encodent nos standards d'architecture, de code, d'écriture des tests, etc. J'ai même des outils où des agents challengent la proposition du premier agent, qui doit démontrer que sa solution fera la bonne chose, par exemple en planifiant déjà des tests automatisés. Pendant l'implémentation, l'agent charge des skills supplémentaires et se fait encore challenger par d'autres agents. Au travers du flow, on peut y voir des plans machine-readables, des agents qui supervisent des agents et de la preuve par tests. Sur l'échelle de Pier-Luc, cette machinerie-là, c'est celle des modes 3 et 4.
Et pourtant, avant que ça parte en production, je garde le même geste, soit de relire ce qui a été fait. Pas uniformément. Je vais vite sur le trivial. Pour l'architecture, je valide la conformité au plan qu'on a déjà approuvé ensemble. Et je mets un grand focus sur les tests générés. Sont-ils clairs et valident-ils la bonne chose de la bonne façon?Les tests sont devenus encore plus importants qu'avant à l'ère de l'IA. L'article des deux ans d'IA a d'ailleurs un nom pour cette façon de travailler. Le sommet de l'échelle est souvent comparé à une « dark factory », une usine si automatisée qu'on peut y éteindre les lumières, puisque plus personne n'est dans la pièce. L'article ajoute un mode 4.5, la « lit factory », qui est le mode où toute la machinerie tourne, mais comme l'humain reste dans la boucle, les lumières ne s'éteignent jamais. C'est une zone où je vais par moments.
Ce quotidien m'a fait voir ce que je cherchais. Les échelles regroupent deux curseurs en un seul. Le curseur de production mesure combien la machine produit sans moi. Le curseur de vérification mesure combien je vérifie ce qu'elle produit. Les échelles font monter les deux ensemble, comme si l'un impliquait l'autre. Mais sur le terrain, rien n'oblige à les coupler. On peut pousser l'automatisation de la production très haut sans jamais signer le transfert de la vérification. Relire n'est donc pas un manque d'outillage, car j'utilise la machinerie des modes supérieurs tous les jours. J'ai simplement séparé les deux curseurs.
DORA parle d'une « taxe de vérification », soit le temps gagné à écrire le code se dépense à le réviser. Cette image suppose une revue de code naïve où chaque ligne est relue également, puis re-relue. Ce n'est pas ce que je fais. Surtout, cette image ne montre qu'un côté de la médaille. Lire le code qu'on livre, ce n'est pas seulement une vérification. C'est aussi un outil de partage de connaissances entre les développeurs et les développeuses, celui qui nous aidera à éteindre d'éventuels feux en production. Arrêter de lire le code, c'est aussi arrêter de comprendre le système. Et donc, est-ce que la revue de code est vraiment une taxe... ou un investissement?
Conseil : Réglez les deux curseurs séparément. Vous pouvez pousser le curseur de production à fond sans toucher au curseur de vérification.
S'il ne me manque pas d'outillage, il reste l'hypothèse de la confiance. Le réflexe du développeur frileux qui n'arrive pas à lâcher prise. Pour vérifier celle-là, il faut revenir en arrière.
J'ai livré ma première application mobile il y a une dizaine d'années. Le matin de Noël, un événement devait se déclencher dans l'application pour offrir des cadeaux aux utilisateurs. Cependant, à 2h du matin, au moment où j'allais me coucher, j'ai reçu un texto du client qui me disait que ça ne marchait pas. Je suis allé régler le problème avant de m'endormir. C'est la seule fois que c'est arrivé, parce que j'ai décidé cette nuit-là d'être beaucoup plus vigilant sur ce que je livre.
Ce texto, c'est ma réponse à la question de la confiance. Lire le code avant la production, ce n'est pas de la méfiance envers l'outil. C'est de l'imputabilité vécue. Si un problème survient pendant la nuit, c'est un développeur ou une développeuse qui va se lever pour le régler. Pas le fournisseur de l'intelligence artificielle. L'article des deux ans d'IA chez Nexapp le dit d'ailleurs lui-même. Peu importe le mode, l'imputabilité reste humaine.
Concrètement, qu'est-ce qui me retient encore? Trois choses.
L'état de l'outil. Au moment d'écrire ces lignes, en 2026, l'IA n'est pas encore rendue au point où je peux la laisser réussir du premier coup dans un logiciel d'entreprise à grande échelle. Je l'interromps souvent en cours de génération parce qu'elle part dans une direction que je n'aurais pas prise. J'ai déjà vu une IA « réparer » un test en remplaçant l'assertion par expect(true).toBe(true). C'était en 2025, et les modèles se sont nettement améliorés depuis. Ce constat-là s'affaiblit à chaque génération. Ça avance, et c'est tant mieux. Mais on n'est pas encore rendus.
La nature du travail. Construire un pont est compliqué. Les inconnus sont nombreux, mais une fois résolus, le pont tient. Développer un logiciel est complexe. Les inconnus ne s'épuisent jamais, à commencer par ce que les utilisateurs veulent vraiment. C'est pour ça qu'on avance par hypothèses, en livrant en continu, en observant et en ajustant. L'IA n'échappe pas à ce monde-là. Elle aussi fait des hypothèses. Non déterministe, elle choisit son contexte, tente une solution, et se trompe parfois, comme nous. La différence, c'est que là où un collègue dit « je pense que », l'IA avance avec pleine confiance, comme si le doute n'existait pas. Dans un monde d'hypothèses, un outil qui ne doute jamais a besoin de quelqu'un qui doute pour lui.
La localisation de l'information. Une partie des réponses ne vit ni dans le ticket ni dans le code. Elle vit dans des conversations entre humains, dans le contexte d'affaires, dans ce que la Product Owner a dit au client la semaine passée. Quand l'information leur manque, les développeurs et les développeuses s'arrêtent et vont la chercher, avec une question à la Product Owner ou une validation avec les utilisateurs. L'IA, elle, comble le trou avec une supposition et continue d'avancer. On me répondra qu'une deuxième IA peut évaluer le travail de la première. Mais elle évaluera avec les mêmes informations manquantes. Aucun modèle, aussi bon soit-il, ne peut valider une information qu'il n'a pas. Et plus on monte dans l'échelle, plus l'IA avance seule. Il reste de moins en moins de monde pour remarquer les questions qui n'ont jamais été posées. Ce constat-là ne périme pas avec les modèles.
Ces constats changent la façon de travailler avec un agent au quotidien. Laisser l'agent travailler seul dans son coin et tout vérifier à la fin, c'est de la revue asynchrone, avec le défaut qu'on lui connaît déjà entre humains. Les commentaires arrivent au moment où ils coûtent le plus cher à appliquer. Si l'agent part dans la mauvaise direction et qu'on s'en aperçoit deux heures plus tard, tout le travail qui a suivi est contaminé, du code aux tests, en passant par les agents qui se challengent et les tokens consommés. L'interrompre en cours de route, c'est du pairing avec la machine. Plus un commentaire arrive tôt, moins il coûte cher, avec un agent comme avec un humain. J'ai creusé cette idée côté humain dans On brisait les silos. L'idée tient encore quand le coéquipier devient une machine.
Relire n'est donc ni un manque d'outillage, ni un manque de confiance. Il me restait à comprendre ce que c'était vraiment, et la réponse est venue en regardant le reste de ma semaine.
Il faut que je sois honnête. Pendant que je défendais la relecture dans ma tête, mes semaines étaient occupées à la contredire sur tout ce qui ne touchait pas au cœur du produit.
Pour évaluer un agent de notre produit, des professionnelles du domaine avaient rempli un fichier Excel de 300 cas réels, et il fallait un script pour le convertir au format que l'agent consomme. L'IA l'a généré de A à Z, puis l'a raffiné à chaque nouvelle version du fichier, sans grande surveillance de ma part. Le jour où l'évaluation se termine, ce script meurt. Personne ne se lèvera la nuit pour lui.
Et ce n'est pas juste moi. Nexapp s'est construit un produit interne pour suivre ses projets, et à chaque fonctionnalité, la même conversation revient. Est-ce que ça touche au cœur du produit ou à ses données, ou c'est une tâche de soutien? Si c'est critique, un développeur la prend, assisté par l'IA. Si ce sont des améliorations de surface, on accepte très bien qu'un gestionnaire qui ne code pas l'ajoute lui-même avec un agent, et qu'il livre.
Regardez ce que ces histoires ont en commun. La décision ne s'est jamais prise par équipe, ni par produit. Elle s'est prise par tâche. Le matin comme l'après-midi, j'utilise les mêmes agents. Ce qui change, c'est ce que je fais du résultat. Le matin, je relis le code du cœur du domaine. L'après-midi, je valide le script jetable sans en lire une ligne. Relire n'a jamais été quelque chose qui me tenait à cœur coûte que coûte. C'était le réglage de ces tâches-là, celles qui vivront des années et pour lesquelles quelqu'un se lèvera la nuit.
C'est ça, la réponse à la question qui a ouvert cet article. Relire tout ce que je livre n'était ni un retard ni une identité. C'était un réglage. Et c'est tout le piège des échelles lues comme un palmarès, où monter serait progresser. C'est pour ça que le mot « mode » me plaît plus que « niveau ». On ne grimpe pas vers un mode, on le choisit. La maturité, ce n'est pas d'être au mode 5. C'est de savoir quel mode choisir pour chaque tâche. Une équipe qui ne lit plus rien sans se poser la question peut être aussi immature qu'une équipe qui relit tout par réflexe.
Si le mode se choisit par tâche, il faut pouvoir trancher vite. Voici les quatre questions qu'on se pose, et que je propose à toute équipe.
Recommandation : Faites de ces quatre questions un réflexe de raffinement, au même titre que l'estimation. Le mode d'une tâche est une décision d'équipe, révisable, pas une politique coulée dans le béton.
Je ne suis jamais allé au mode 5. Pas par principe, et pas par prudence. Rien dans mon contexte actuel ne l'a justifié jusqu'ici. Mais je reste à l'affût. Chaque fois que se présente une tâche jetable, qui ne peut pas briser grand-chose et pour laquelle personne ne se lèvera la nuit, je me contente de valider, et avec plaisir. Ces occasions sont de plus en plus fréquentes à mesure que les outils s'améliorent.
C'est ce que je répondrais aujourd'hui à la personne qui, comme moi en lisant sa première échelle, se demande si sa façon de travailler est un retard. La carte est utile. L'échelle de Pier-Luc montre quels modes existent; elle donne à une organisation un cap et un vocabulaire commun. Mais la carte ne dira jamais quel mode choisir pour la tâche de lundi matin. Pour ça, il faut une boussole, soit les quatre questions posées tâche par tâche. Et cette boussole est entre les mains de votre équipe.
Alors ne demandez plus à votre équipe quel est son niveau. Demandez-lui plutôt comment elle choisit le mode de chaque tâche. Si elle sait répondre, vous êtes entre de bonnes mains, peu importe le mode où elle passe ses journées. Elle sait déjà qui doit lire quoi avant la production.
La question de la confiance envers un code que personne n'a lu déborde d'ailleurs déjà du génie logiciel. La faculté de droit de Stanford se demande publiquement qui peut faire confiance à un logiciel construit et testé par des agents. La conversation ne fait que commencer.
En attendant, une chose ne change pas : peu importe le niveau affiché sur l'échelle, le texto de 2h du matin, lui, arrive toujours sur le téléphone d'un humain.