Quand nous avons commencé à utiliser sérieusement l’IA dans nos développements, le premier réflexe a été le plus évident : lui demander de produire. Du code, des interfaces, des tests, des contenus, des migrations — plus, et plus vite. Le résultat est spectaculaire, au point qu’on en oublie de se poser la seule question qui compte vraiment.
Car plus une IA produit, plus une autre question devient urgente : qui contrôle ce qu’elle vient de produire ?
Un résultat qui fonctionne n’est pas un bon résultat
C’est le piège dans lequel une équipe tombe presque toujours en premier. On regarde si « ça marche ». L’écran s’affiche, le workflow s’exécute, la tâche est faite. On coche, on passe à la suite.
Mais un développement peut fonctionner tout en étant inutilement complexe. Un workflow peut tourner en reposant sur une logique bancale. Une automatisation peut faire gagner du temps à une personne en créant, ailleurs, une dépendance, un coût ou une fragilité que personne ne verra avant des mois.
L’IA est remarquable pour répondre à la demande formulée. Elle est bien moins portée à la remettre en cause. Si je lui demande de construire une fonctionnalité, elle la construit. Elle ne me dit pas spontanément « cette fonctionnalité existe déjà ailleurs dans le produit », ni « son coût de maintenance sera disproportionné par rapport à son usage ». Elle exécute la commande. Le doute, il faut l’organiser à part.
Deux rôles qu’il ne faut jamais confondre
De cette pratique est née, chez nous, une distinction que je crois structurante. Il n’y a pas un agent IA. Il y en a deux, avec des missions opposées.
L’agent producteur exécute. Il développe, rédige, migre, documente, automatise. Son objectif est un résultat exploitable, vite. Il travaille dans le cadre qu’on lui a donné, et il le fait bien. C’est celui qu’on remarque, celui qui impressionne.
L’agent contrôleur, lui, cherche d’abord ce qui cloche. Cohérence avec l’existant, doublons, risques de sécurité, dépendances ajoutées, coûts futurs, qualité des tests, maintenabilité, effets de bord — et parfois la question la plus dérangeante de toutes : ce développement était-il seulement pertinent ? Son travail est moins visible. Il ne livre rien. Il empêche.
Le premier agent défend la capacité à livrer. Le second défend la qualité, la simplicité et la maîtrise des risques.
Et pour que ce second rôle ait un sens, il faut lui accorder un droit que l’on donne rarement à un outil : le droit de contredire. Contredire le premier agent, et parfois la personne qui a demandé le travail. Un contrôleur qui ne peut pas dire non n’est pas un contrôleur, c’est une formalité.
Pourquoi ce ne peut pas être le même agent
La tentation est grande de faire l’économie du second agent : « demandons au premier de relire son propre travail ». C’est une fausse bonne idée, et pour une raison très humaine.
Un agent qui vient de concevoir une solution est influencé par ses propres choix. Il ne repart pas d’une feuille blanche — il les justifie. On lui demande de se contredire, il s’auto-félicite. Ce biais, nous le connaissons bien chez les humains ; il ne disparaît pas parce qu’on l’a confié à une machine.
C’est pour cela qu’une règle simple gouverne, chez nous, tout ce qui touche à la validation : un agent producteur n’a pas l’autorité de valider son propre travail. Deux principes en découlent, non négociables. On n’approuve jamais une modification pendant qu’on la revoit — l’approbation reste réservée aux humains. Et on n’approuve jamais si des tests manquent. Une MR ne peut être fusionnée que sur deux conditions cumulées : pipeline vert et revue explicite. Pas l’un ou l’autre. Les deux.
La séparation des rôles n’est donc pas une élégance d’organisation. C’est le seul moyen de ne pas transformer un audit en cérémonie d’auto-satisfaction.
Le choix se fait avant même de lancer la tâche
Là où la théorie devient une discipline concrète, c’est au moment du dispatch. Chez nous, on choisit le modèle selon le rôle, et ce choix est obligatoire et explicite : un modèle rapide et économique produit, un modèle plus lourd conteste. Le producteur avance vite et pour pas cher ; le contrôleur prend le temps et la puissance qu’il faut pour trouver ce qui ne va pas.
Ce n’est pas une préférence, c’est une contrainte technique assumée : notre API interne rejette toute demande d’agent sans modèle choisi. Impossible de dispatcher une tâche par défaut, sans avoir tranché qui produit et qui juge. Jamais de défaut silencieux — parce qu’un défaut silencieux, c’est exactement le moment où l’on oublie d’organiser la contradiction.
Pour les changements structurants, on va plus loin encore. La revue passe par une commande dédiée, et dans sa version la plus exigeante, elle lance une revue multi-agents adversariale dans le cloud : plusieurs agents ne cherchent pas à approuver le travail, ils cherchent à le réfuter. Ils reviennent avec une liste d’écarts classés par sévérité, pas avec un satisfecit. C’est inconfortable, et c’est précisément l’objectif.
Organiser la contradiction comme un processus
Rien de tout cela ne fonctionne comme une bonne intention. Ça fonctionne comme un enchaînement de rôles :
- un agent propose et développe ;
- un autre agent audite, sans avoir participé à la production ;
- les écarts sont classés par niveau de risque, pas mis en vrac ;
- une décision humaine tranche — c’est là, et seulement là, que l’approbation existe ;
- les corrections sont vérifiées une seconde fois avant de fusionner.
Oui, c’est un peu plus lent les premières heures. Mais ce sont des heures qui évitent de perdre des jours ensuite — à défaire une architecture trop complexe, à retrouver un doublon parti en production, à réparer une dépendance que personne n’avait pesée. J’ai déjà raconté ailleurs, dans un autre article de cette série, comment un audit de ce type exhume ce que l’habitude nous rend invisible ; ici, l’enjeu est en amont : ne pas laisser produire sans que quelqu’un ait le mandat de dire stop.
Le vrai changement n’est pas la vitesse, c’est l’organisation
C’est le point que je voudrais laisser à un dirigeant qui équipe ses équipes en IA. On croit acheter de la vitesse. On achète surtout un déséquilibre.
Plus la capacité de génération augmente, plus la capacité de revue doit suivre — sinon on accélère la quantité sans renforcer la qualité. Une entreprise qui n’outille que ses producteurs ne devient pas plus forte ; elle devient plus rapide à accumuler ce qu’elle ne relit plus. La prochaine étape n’est pas de déployer davantage d’agents qui construisent. C’est d’en désigner certains pour une mission moins gratifiante, presque ingrate : nous empêcher de confondre vitesse et maîtrise.
L’IA est un formidable moteur de production. Elle devient une alliée sérieuse le jour où l’on accepte d’en dresser une partie contre l’autre.
Et chez vous — qui a le droit de dire à votre IA que ce qu’elle vient de produire ne devrait pas exister ?