Aller au contenu

L'humain est le nouveau CI/CD de l'IA

· Par Jean-Noé Kollo

Pendant vingt ans, les humains produisaient et les machines vérifiaient. L'IA a inversé le sens. Vous n'êtes pas un CI/CD plus lent — vous êtes la couche là où les tests au vert deviennent aveugles.

Pendant vingt ans, l'automatisation est allée dans un seul sens. Les humains produisaient. Les machines vérifiaient.

L'IA générative a inversé le sens. Désormais la machine produit et c'est toi qui vérifies.

Ça ressemble à une promotion. Ça n'en est pas une — pas encore. C'est un autre métier, et il vient avec un piège dans lequel la plupart des équipes tombent tête baissée.

Vingt ans, un seul sens

Depuis que le CI/CD est devenu la norme, nous avons sorti l'humain du chemin critique répétitif. Les tests manuels sont devenus des tests automatisés. Le déploiement manuel est devenu le CD. La vérification est devenue le CI. Nous avons automatisé l'exécution et le contrôle pour gagner en vitesse et en régularité.

L'humain a gardé le jugement — écrire les tests, approuver les merges, assumer la release. Mais sur la chaîne de production elle-même, le schéma était figé. Les humains produisaient, les machines vérifiaient. Ce sens ne s'est jamais inversé.

Maintenant, c'est la machine qui produit

L'agent écrit le code. Tu le relis. Sur cet axe, les rôles se sont vraiment échangés, et tu reprends la place qu'occupait la machine : le point de contrôle.

Mais ce n'est pas l'ancien métier restauré. C'en est un nouveau.

Deux roles, un seul savoir-faire

Le développement classique est déterministe. Entrées définies, sortie prévisible, tu es propriétaire de chaque ligne. Ça se comporte comme une science.

La construction assistée par IA est probabiliste. Tu exprimes une intention et tu obtiens un résultat probable, pas un résultat certain, parce que le modèle est une boîte noire. Tu ne codes plus. Tu pilotes.

Ce nouveau pôle porte une dizaine de noms — AI engineer, AI builder, applied AI — et aucun ne tient. Sous les étiquettes, il n'y a qu'une seule chose : le vibe coding.

Aucun des deux pôles n'est pur. Le développement classique n'a jamais été parfaitement déterministe ; quiconque a couru après un test flaky le sait. Et le nouveau métier est très encadré, ce n'est pas le chaos.

Ce qui les sépare, c'est ce dont tu es propriétaire. À un pôle, tu possèdes la solution — les lignes qui résolvent le problème. À l'autre, tu possèdes les conditions dans lesquelles une solution a le droit d'exister : l'intention, les contraintes, les portes qui décident de ce qui survit.

Et le nouveau pôle peut exister seul. Un amateur livre en un après-midi une fonctionnalité que tu aurais chiffrée en semaines, sans aucun métier dessous. Quand l'enjeu est faible, ça passe. Monte l'enjeu et ça s'inverse. Le nouveau pôle ne vaut quelque chose que lorsque l'ancien métier se trouve dessous, parce que le jugement découle du métier. Tu ne peux pas dire si la boîte noire a produit quelque chose de bon si tu ne sais pas déjà à quoi ressemble le bon — et ça, ça se construit au pôle déterministe, ligne après ligne, pendant des années.

La dépendance n'est donc pas symétrique. Ce ne sont pas deux métiers qui ont besoin l'un de l'autre. C'est une seule compétence coupée en deux : les mains d'un côté, le jugement de l'autre. Quand l'enjeu est fort, le jugement ne vaut que ce que valaient les mains dont il se souvient.

Le jugement devient le point de blocage

Voilà le piège. Le point de contrôle humain n'a rien à voir avec la pipeline sur laquelle il se pose. Le CI/CD était rapide, régulier, infatigable. Tu es lent, tu fatigues, et tu tamponnes dès que le volume devient trop élevé.

Tu n'es donc pas un CI/CD plus lent. Les portes automatisées ne disparaissent pas — elles tournent toujours sur le code de l'IA. Tu es une nouvelle couche placée exactement là où ces portes sont aveugles : le jugement. La conformité à l'intention. La cohérence architecturale. L'arbitrage de sécurité. Tout ce qu'un test au vert ne peut pas attraper.

Et le jugement devient la ressource la plus précieuse au moment précis où il devient le plus difficile à exercer. L'IA fait exploser le volume, mais le jugement ne passe pas à l'échelle. Plus la machine produit, plus il y a à juger — pendant que la capacité de jugement reste plate, et chute avec la fatigue.

La solution tentante consiste à t'aider à juger plus vite. C'est une impasse. Un humain qui valide à la chaîne ne juge plus, il tamponne, et le point de contrôle devient du théâtre. Accélère le jugement et tu le détruis.

Juger moins de choses, mais les bonnes

La question n'est donc pas comment juger plus vite. C'est comment juger moins de choses, mais les bonnes.

En aval, trie par le risque. Tout ce qui est réversible et jetable passe par les seules portes automatisées. Tout ce qui touche à la sécurité, à l'irréversible, à l'architecture remonte jusqu'à toi. Tu ne vois pas mille pull requests. Tu vois les vingt qui peuvent faire mal.

En amont, cadre l'intention. Un pourquoi et un quoi bien posés dérivent moins. C'est pour ça que le spec-driven development revient en force. L'ironie est superbe : l'IA devait nous libérer de la spec, elle la rend plus vitale que jamais.

Voilà à quoi ça a ressemblé chez moi. J'accepte la boîte noire. Alors plutôt que de gouverner chaque étape, j'enferme les agents dans un parcours zero-trust — une longue série de portes automatisées que chaque changement doit franchir avant de gagner le droit d'être mergé, conçue pour que tout ce qui en sort soit forcé d'atterrir sur mon intention. J'ai mis ça dans un outil que j'ai construit, Ferry, qui pilote une vraie application en production depuis trois mois. Les agents prennent un ticket, écrivent, se relisent entre eux et mergent tout seuls. Rien n'arrive en production sans avoir passé toutes les portes.

Et si ce jugement vaut quelque chose, c'est parce qu'il ne se réduit pas à une règle. Si c'était le cas, nous l'aurions déjà automatisé. C'est la capacité à assumer un arbitrage dans l'ambiguïté : laisser passer un risque en connaissance de cause parce que la deadline l'exige, bloquer un travail qui passe tous les tests mais qui te met mal à l'aise, choisir entre deux options défendables. Une pipeline ne sait pas faire ça. Toi, si — et tu en réponds.

Mais qui capte la valeur ?

Ce basculement soulève une question en sourdine, et ce sont les dirigeants qui devraient la poser. Quand une compétence rare devient abondante, où passe sa valeur ?

Elle ne disparaît pas. Une compétence qui demandait des années à construire et se vendait avec une prime est désormais produite à la demande par un modèle que n'importe qui peut louer. La prime s'effondre, mais la valeur qu'elle portait migre. Une partie va vers celui qui possède le modèle, qui capte maintenant, sur chaque tâche, l'écart entre ce que la machine produit et ce qu'elle coûte à faire tourner. Le reste s'accumule au seul endroit que le modèle ne peut pas encore occuper — le jugement qui décide de ce qui a le droit de partir en production.

Tu ne montes donc pas simplement vers un rôle plus noble. Tu recules vers la dernière position où le travail conserve une valeur que le propriétaire du modèle n'a pas captée.

Ça change aussi ce que nous payons. L'expérience qui circulait librement entre praticiens — ce que tu absorbais de tes collègues, en lisant le code des autres, au fil des années sur le terrain — passe maintenant par un modèle et se facture au token. Un bien commun gratuit et direct devient un service au compteur.

Pour une entreprise qui lit le monde en coût d'accès et en dépendance fournisseur, c'est là qu'est la vraie ligne budgétaire. Pas l'abonnement. Le transfert lent d'une capacité que tu possédais vers une capacité que tu loues, et la dépendance qui se durcit le jour où tes propres équipes cessent de la construire elles-mêmes.

Et cette érosion n'est pas un choix qu'une entreprise fait une fois pour toutes. C'est une pente. L'équipe qui maintient sa compétence en vie coûte plus cher à court terme que celle qui la laisse fondre, et la pression sur les coûts pousse donc structurellement vers l'atrophie — jusqu'au jour où le risque contre lequel elle assurait finit par arriver.

Ce qui recadre le goulot d'étranglement. La limite n'est plus la machine. C'est le jugement humain posé par-dessus. Mais économiquement, le goulot est aussi là où se loge la marge. Celui qui possède le point de passage — le modèle en dessous ou le jugement au-dessus — possède la valeur que produit tout le reste de la chaîne.

La question de la productivité est réglée ; la machine y a répondu. La question ouverte pour les années à venir est celle de la répartition. À mesure que la production devient abondante et quasi gratuite, la valeur se concentre aux deux extrémités qui restent rares : le modèle et le jugement. Ce sont les deux pôles de tout à l'heure, lus du côté de la valeur plutôt que du côté de la compétence. Les mains, qui étaient l'un des deux, sont devenues le milieu abondant, et la marge s'accumule aux extrémités.

La partie qui s'amincit, c'est précisément le travail d'exécution sur lequel la plupart d'entre nous ont bâti leur carrière. Le mouvement stratégique n'est donc plus de produire plus vite. C'est de décider laquelle de ces extrémités rares tu comptes posséder, parce que le milieu est la partie qui ne se paie plus.

L'IA ne nous a pas sortis de la boucle. Elle nous a déplacés au seul endroit que la machine ne peut pas atteindre : juger ce qui mérite d'être jugé.