Nous sommes à un tournant du développement logiciel. Le débat porte souvent sur le fait de savoir si laquelle l'IA écrit le meilleur code (Claude vs. ChatGPT) ou où où cette IA doit résider (IDE ou CLI). Mais ce n'est pas la bonne question.
Si nous adoptons l'IA en tant que « Vibe Coders » – où nous exprimons l'intention et où l'IA réalise l'exécution – nous créons un flux massif de nouveaux logiciels. Un escadron d'agents IA peut générer en une minute plus 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 d'humains. La solution est une Autorité de Conception IA.
Traditionnellement, « l'Autorité de Conception » (Design Authority) est un 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 d'IA à haute vélocité ce modèle est désespérément obsolète. Il est trop lent et trop réactif.
Si nous passons au « Code Jetable » (Disposable Code) – des logiciels que nous ne refactorisons pas sans fin, mais que nous jetons et régénérons lorsque les exigences changent – notre rôle change fondamentalement. Nous ne sommes plus des maçons posant pierre par pierre. Nous sommes les architectes de l'usine qui imprime les murs.
Mais qui vérifie que ces murs sont droits ?
Une AI Design Authority n'est pas une personne, mais un pipeline. Une "Gauntlet" (épreuve) par laquelle chaque ligne de code générée doit se battre pour atteindre la production. Ce processus ne remplace pas la revue de code humaine par rien, mais par quelque chose de mieux.
Il fonctionne en trois couches :
1. Le Pouvoir Exécutif (La Génération)
Nous ne demandons pas à un seul modèle d'IA 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 est également validée scientifiquement et démontre qu'il est possible de prévenir les hallucinations de l'IA et de construire de très longues chaînes sans erreurs
2. Le Filtre Rigoureux (La Loi)
Ici, aucune discussion n'est possible. Le code doit compiler. Les linters ne doivent pas broncher. Et de façon cruciale, les tests boîte noire doivent réussir. Nous ne testons pas si la fonction fonctionne en interne (ce que l'IA peut manipuler), nous testons si le système fait extérieurement ce qu'il est censé faire. Le test échoue ? Directement à la poubelle.
3. Le filtre souple (Le jury IA)
C'est la véritable innovation. Les solutions restantes sont soumises à une "Voting AI" (IA de vote) spécialisée. Cet agent ne rédige pas de code, mais lit du code. Il est entraîné sur nos principes d'architecture, nos exigences de sécurité (OWASP, ISO) et nos règles de conformité (EU AI Act).
Il vote : « La solution A est plus rapide, mais la solution B est plus sûre et s'intègre mieux dans notre architecture de microservices. »
Le gagnant passe en production.
Ce modèle impose une séparation des pouvoirs qui fait défaut dans de nombreuses équipes.
project-description.md, rules.md, skills.md en principles.md), les exigences strictes. L'architecte détermine ce ce que nous construisons, qui le construit, comment et pourquoi.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 plus de savoir si l'IA peut écrire notre code. Ce débat est clos. Le code est en train de devenir largement un produit jetable.
La question est : osez-vous abandonner le contrôle de la code pour reprendre le contrôle de la qualité ?
faites-le-moi savoir