L’Autorité de conception IA

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

Si nous adoptons l’IA comme des « Vibe Coders » — en indiquant notre intention et en laissant l’IA se charger de l’exécution — nous créons un flux considérable de nouveaux logiciels. Un essaim d’agents IA peut générer en une minute davantage de code qu’un développeur senior ne peut en examiner en une semaine. L’être humain est devenu le goulot d’étranglement.

La solution n’est pas de plus remplacer les humains. La solution est une Design Authority IA.

De l’artisan au directeur d’usine

Traditionnellement, la « Design Authority » 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 logiciel à haute vélocité assisté par l’IA ce modèle est désespérément dépassé. Il est trop lent et trop réactif.

Si nous passons au « Disposable Code » — des logiciels que nous ne refactorisons pas indéfiniment, mais que nous abandonnons et régénérons lorsque les exigences changent — notre rôle évolue fondamentalement. Nous ne sommes plus des maçons qui construisent pierre après pierre. 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 traverser pour parvenir jusqu’en production. Ce processus ne remplace pas la revue de code humaine par rienmais par quelque chose de meilleur.

Il fonctionne en trois couches :

1. Le pouvoir exécutif (la génération)
Nous ne demandons pas à une seule IA de trouver une solution, mais à trois. Nous faisons travailler en parallèle Gemini 3, GPT-5 et un modèle open source (comme Llama) sur le même problème. Cela évite la vision en tunnel et brise la « paresse » dont les LLM souffrent parfois. Cette approche est également é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 surtout, 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 ce qu’il doit faire de l’extérieur. Le test échoue ? Direction la corbeille.

3. Le filtre souple (le jury IA)
C’est la véritable innovation. Les solutions restantes sont soumises à une « IA de vote » spécialisée. Cet agent n’écrit pas de code, mais lit 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 se prononce : « La solution A est plus rapide, mais la solution B est plus sûre et respecte mieux notre architecture 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 ce que ce que nous construisons, qui le construit, comment et pourquoi.
• Le pouvoir exécutif (les agents de codage) : Ils exécutent. Rapidement, à moindre coût et sous l’égide de développeurs humains.
• Le pouvoir judiciaire (l’Autorité de conception) : 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 bien : la pensée systémique. La recherche de la vérité. La structuration 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 lâcher le contrôle du code pour ainsi reprendre le contrôle de la qualité le reprendre ?

faites-le-moi savoir