L’autorité de conception de l’IA

Nous sommes à un tournant dans le développement logiciel. Le débat porte souvent sur la question de savoir quelle si l’IA écrit le meilleur code (Claude ou ChatGPT), ou où où cette IA doit être intégrée (IDE ou CLI). Mais ce n’est pas la bonne question.

Si nous adoptons l’IA comme des « codeurs Vibe » — en indiquant notre intention et en laissant l’IA se charger de l’exécution — nous générons un flux considérable de nouveaux logiciels. Une nuée d’agents d’IA peut produire en une minute davantage de code qu’un développeur senior ne peut en examiner en une semaine. L’humain est devenu le goulot d’étranglement.

La solution n’est pas plus les humains. La solution est une instance de gouvernance de conception de l’IA.

De l’artisan au directeur d’usine

Traditionnellement, l’« instance de gouvernance de conception » est un petit groupe d’architectes qui se réunit une fois par semaine ou par mois pour approuver ou rejeter une conception. Dans un monde de développement de l’IA à haute vélocité ce modèle est totalement obsolète. Il est trop lent et trop réactif.

Si nous passons au « code jetable » — des logiciels que nous ne refactorisons pas indéfiniment, mais que nous supprimons et régénérons lorsque les exigences changent — notre rôle évolue fondamentalement. Nous ne sommes plus des maçons qui posent les pierres une à une. Nous sommes les architectes de l’usine qui imprime les murs.

Mais qui vérifie que ces murs sont bien droits ?

Le « Gauntlet » : une épreuve du feu automatisée

Une autorité de conception de l’IA n’est pas une personne, mais un pipeline. Un « parcours du combattant » que chaque ligne de code générée doit franchir pour atteindre la production. Ce processus ne remplace pas la revue de code humaine par rien, mais par quelque chose de meilleur que.

Il fonctionne selon trois niveaux :

1. Le pouvoir exécutif (la génération)
Nous ne demandons pas à une seule IA de trouver une solution, nous en sollicitons trois. Nous faisons travailler Gemini 3, GPT-5 et un modèle open source (comme Llama) en parallèle sur le même problème. Cela évite la vision en tunnel et brise la « paresse » dont les LLM souffrent parfois. Cette approche a également été étudiée scientifiquement et montre qu’il est possible d’éviter les hallucinations de l’IA et de construire de très longues chaînes sans erreurs

2. Le filtre strict (la loi)
Ici, aucune discussion n’est possible. Le code doit compiler. Les linters ne doivent signaler aucune erreur. Et, point crucial, les Tests en boîte noire doivent réussir. Nous ne testons pas si la fonction fonctionne en interne (l’IA pourrait le manipuler), mais si le système fait extérieurement ce qu’il est censé faire. Le test échoue ? Direction la poubelle.

3. Le filtre souple (le jury IA)
C’est là que se trouve la véritable innovation. Les solutions restantes sont soumises à une « IA de vote » spécialisée. Cet agent n’écrit pas de code, mais il lit évalue le code. Il a été entraîné sur nos principes d’architecture, nos exigences de sécurité (OWASP, ISO) et nos règles de conformité (règlement européen sur l’IA).
Il vote : « La solution A est plus rapide, mais la solution B est plus sûre et s’intègre mieux à notre architecture de microservices. »

Le gagnant passe en production.

La séparation des pouvoirs dans le logiciel

Ce modèle impose une séparation des pouvoirs qui fait défaut dans de nombreuses équipes.

• Le pouvoir législatif (l’architecte) : L’architecte rédige la « Constitution ». Les prompts, les documents d’architecture (project-description.md, rules.md, skills.md en principles.md), les exigences strictes. L’architecte détermine quoi ce que nous construisons, qui le construit, comment et pourquoi.
• Le pouvoir exécutif (les agents de programmation) : Ils exécutent. Rapidement, à moindre coût et sous la supervision de développeurs humains.
• Le pouvoir judiciaire (la Design Authority) : Une couche d’IA indépendante qui vérifie la conformité à la loi.

Conclusion : le nouveau rôle de l’architecte

Il nous libère de la tyrannie des erreurs de syntaxe et nous permet de nous concentrer sur ce que nous faisons de mieux : la pensée systémique. La recherche de la vérité. La structure et la prise de décision.

La question n’est pas de savoir si l’IA peut écrire notre code. Ce sujet est déjà clos. Le code devient en grande partie un produit jetable.
La question est : osez-vous renoncer au contrôle de la code pour reprendre ainsi le contrôle du qualité ?

faites-le-moi savoir