💻 computer science

From Requirements to Production: Governing AI-Assisted Software Delivery through a Canonical Requirements Model

Cet article présente une étude de science de la conception introduisant un cadre de gouvernance pour la livraison de logiciels assistée par l'IA qui utilise un modèle de exigences canonique, une boucle de construction et de revue à double fournisseur, ainsi qu'une documentation exécutable afin d'atteindre une traçabilité et une conformité élevées à travers deux systèmes de production indépendants tout en redéfinissant le rôle de l'analyste d'affaires.

Auteurs originaux : Mohamed Zahran

Publié 2026-07-21

📖 8 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Mohamed Zahran

Article original sous licence CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Les nouvelles règles de la route pour les bâtisseurs de robots

Imaginez que vous êtes un architecte chevronné qui a passé des années à dessiner des plans pour des équipes de construction humaines. Vous savez que si vous laissez une minuscule lacune dans les plans — comme oublier de préciser la couleur de la porte d'entrée — un constructeur humain qualifié se contentera de vous demander : « Hé, de quelle couleur voulez-vous la porte ? » ou devinera en fonction du style du quartier. Ils comblent les vides avec leur propre bon sens et leur expérience. C'est ainsi que le développement de logiciels fonctionne depuis des décennies : un humain écrit les exigences, et une équipe humaine construit le logiciel, en remplissant les détails manquants au fur et à mesure.

Mais maintenant, imaginez que vous engagiez une flotte de constructeurs robots, super rapides et super intelligents. Ces robots sont incroyables ; ils peuvent poser des briques et câbler des circuits en quelques secondes. Cependant, ils ont un défaut majeur : ce sont des littéralistes. Ils n'ont pas de bon sens, ils ne devinent pas, et ils ne posent certainement pas de questions. Si vous dites à un robot de « construire une porte » mais que vous ne précisez pas la couleur, il pourrait la peindre en vert fluo parce que c'est la couleur la plus logique dans sa base de données, ou il pourrait s'arrêter et planter parce qu'il ne sait pas quoi faire. Dans le monde du logiciel, c'est le défi de l'assistance au développement par l'IA. Les « exigences » (les instructions) qui fonctionnaient parfaitement pour les humains sont désormais dangereuses pour les robots car les robots ne peuvent pas combler les vides. Si les instructions ne sont pas parfaites, les robots construisent la mauvaise chose, et cela arrive si vite que l'erreur est déjà présente dans le produit final avant même que quiconque ne s'en aperçoive. Ce document explore comment réécrire les règles de la route afin que ces bâtisseurs robots puissent être dignes de confiance pour construire des logiciels sûrs et fonctionnels sans avoir besoin qu'un humain leur tienne la main chaque seconde.

De « Peut-être » à « Doit » : Une nouvelle façon de construire avec l'IA

Le document, écrit par Mohamed Zahran, s'attaque à un problème de taille : les agents de codage IA sont rapides, mais ils sont dangereux si les instructions ne sont pas parfaites. L'auteur soutient que l'ancienne méthode de rédaction des exigences — des documents conçus pour des équipes humaines capables de « lire entre les lignes » — est obsolète lorsque le bâtisseur est une machine. Si un humain lit une instruction incomplète, il utilise son cerveau pour la corriger. Si un robot lit une instruction incomplète, il se contente de deviner, et cette supposition se transforme souvent en bug ou en faille de sécurité.

Pour y remédier, l'auteur n'a pas seulement écrit une nouvelle théorie ; il a réellement construit deux systèmes logiciels fonctionnels en utilisant une nouvelle méthode qu'il a conçue. Considérez cela comme un chef qui, au lieu de simplement écrire un livre de cuisine, aurait cuisiné deux plats complexes différents dans une cuisine sous haute pression pour prouver que sa nouvelle recette fonctionne.

L'idée centrale : La « Source unique de vérité »
La solution de l'auteur est un « Cadre de livraison gouverné et prêt pour l'IA » (Governed AI-Ready Delivery Framework). Le plus grand changement consiste à s'éloigner des documents vagues (comme les fichiers Word) qui peuvent devenir désordonnés et présenter des versions divergentes d'une même chose. À la place, il a créé un Modèle d'exigences canonique.

L'analogie : Imaginez un plan directeur numérique maître qui réside dans un coffre-fort sécurisé. Ce plan est la seule véritable version du projet.
La magie : À partir de ce plan directeur unique, le système génère automatiquement deux « vues » différentes :
1. La vue humaine : Un document lisible et agréable pour l'analyste métier et les gestionnaires afin de valider le projet.
2. La vue robot : Un ensemble d'instructions strictes et lisibles par machine pour les agents de codage IA.
Pourquoi c'est important : Parce que les deux vues proviennent du même plan directeur maître, elles ne peuvent jamais diverger. L'humain ne peut pas valider un plan que le robot n'est pas réellement en train de suivre. C'est comme avoir une source unique de vérité qui met tout le monde à jour instantanément.

La règle des « quatre yeux » pour les robots
Le document introduit un contrôle de sécurité ingénieux appelé Séparation des tâches, mais pour les robots.

La configuration : L'auteur a utilisé deux outils de codage IA différents provenant de deux entreprises (fournisseurs) distinctes.
Le processus : Une IA (Fournisseur A) était le « Bâtisseur ». Elle a écrit le code basé sur les instructions. Une IA complètement différente (Fournisseur B) était l'« Inspecteur ». Elle a examiné le code pour vérifier les erreurs, les failles de sécurité et si celui-ci correspondait bien au plan.
Le résultat : Cela a empêché l'IA de construire une maison et de s'attribuer ensuite une note de réussite. L'IA « Inspecteur » a détecté ce que l'IA « Bâtisseur » avait manqué, tout comme le ferait une équipe humaine.

Les conclusions : La vitesse sans le chaos
L'auteur a testé ce cadre sur deux projets très différents :

Cas 1 : Une plateforme de protection pour 170 organisations nationales (un projet vaste, complexe et lent).
Cas 2 : Un espace de travail d'analyse multi-locataire pour les analystes métier (un projet plus rapide et plus petit avec des règles de sécurité supplémentaires pour les cartes de crédit).

Les résultats sont impressionnants. Le cadre a permis à l'IA de travailler incroyablement vite tout en gardant le contrôle :

Traçabilité : Le système a suivi l'origine de chaque morceau de code. Dans le Cas 1, 94,9 % des exigences étaient parfaitement liées au code et aux tests ; dans le Cas 2, ce chiffre était de 97,8 %.
Aucune modification non autorisée : Dans les deux cas, le taux de modifications non autorisées était de 0,00 %. Le système était si strict que personne (ni aucun robot) ne pouvait modifier discrètement le code sans que le système ne le sache.
Moins d'erreurs : Le « taux d'échappement de défauts » (les bugs qui atteignent le produit final) était de 9,1 % dans le premier cas et de 4,7 % dans le second. Le second cas était d'ailleurs meilleur que la moyenne de référence de l'industrie.
Vitesse : Le cadre n'a pas ralenti les processus. En fait, le second projet a été livré en seulement 31 jours calendaires (avec seulement 12 jours de construction actifs), ce qui est incroyablement rapide pour ce niveau de complexité.

Ce que l'auteur considère comme n'étant pas la solution
Le document est très clair sur ce qui ne fonctionne pas. Il soutient que l'on ne peut pas simplement donner une consigne vague à une IA et la laisser improviser le reste. Il prévient également que l'ajout de l'IA à un projet simplement parce que c'est « à la mode » est une mauvaise idée ; parfois, un simple changement de processus est préférable à l'utilisation de l'IA. L'auteur souligne que l'IA ne peut pas remplacer le jugement humain, la clarté métier ou la nécessité pour un humain d'approuver le résultat final.

Quelle est notre certitude ?
L'auteur prend soin de ne pas prétendre que ceci est une solution miracle qui résoudra tout pour toujours. L'étude est basée sur deux cas spécifiques réalisés par la même personne (l'auteur). Bien que les résultats soient très solides et cohérents à travers deux types de projets très différents, l'auteur admet qu'en tant qu'unique personne à effectuer le travail, nous ne pouvons pas être sûrs à 100 % que cela fonctionnerait exactement de la même manière pour une équipe entière de personnes différentes sans tests supplémentaires. Ils ont également constaté que, bien que le système soit excellent pour détecter les erreurs évidentes, il manquait parfois des « défaillances silencieuses » (des bugs qui ne se manifestent pas immédiatement), ce qui signifie que les humains doivent toujours effectuer des vérifications approfondies de temps à autre.

La grande conclusion
Le document conclut que le rôle de l'Analyste Métier est en train de changer. Ils ne sont plus seulement des rédacteurs de documents pour d'autres humains. Ils deviennent les architectes de systèmes de contrôle. Leur travail consiste à concevoir le « cadre de livraison gouverné » — les règles, les contrôles et le plan directeur — qui permet à l'IA de construire des logiciels en toute sécurité. L'avenir ne porte pas sur l'humain contre l'IA, mais sur l'humain concevant les instructions parfaites pour que l'IA puisse effectuer le gros du travail sans rien casser. Comme le dit l'auteur : « À l'ère de l'IA, l'analyste métier n'est plus défini uniquement par ce qu'il écrit, mais par ce qu'il permet aux autres — humains et IA — de livrer. »

Résumé technique : Gouverner la livraison de logiciels assistée par l'IA via un modèle de exigences canonique

1. Énoncé du problème

Le document identifie une déconnexion fondamentale entre l'ingénierie des exigences traditionnelle et la livraison de logiciels assistée par l'IA. Les analystes d'affaires (BA) ont historiquement produit des artefacts (par exemple, des documents d'exigences métier, des user stories) conçus pour des équipes de livraison humaines. Ces documents reposent sur la « connaissance tacite », le jugement métier et la conversation pour combler les lacunes de spécification. Lorsque l'exécuteur passe d'un développeur humain qualifié à un agent de codage autonome par IA, ce contrat implicite se brise. Les agents d'IA ne déduisent pas les détails manquants ; ils procèdent selon « l'interprétation la plus plausible », transformant les spécifications incomplètes en sources de défauts.

De plus, le papier soutient que l'accent actuel de l'industrie sur la vitesse conduit souvent à l'hypothèse dangereuse que l'analyse métier structurée est inutile. Les preuves suggèrent que sans une définition rigoureuse du problème et une gouvernance, les projets d'IA souffrent de taux d'échec élevés en raison d'une inadéquation avec le flux de travail, d'une insuffisance de données et d'une faible appropriation. Le problème central est l'absence d'un cadre de gouvernance permettant aux agents d'IA d'exécuter les exigences de manière fiable tout en préservant la responsabilité humaine, la traçabilité et la séparation des tâches.

2. Méthodologie

L'étude emploie une approche de Recherche par Conception (Design Science Research - DSR). La contribution est un artefact opérationnel intentionnel — un cadre de livraison gouverné — construit, appliqué et affiné lors de la livraison de deux systèmes de production indépendants et réels.

Cadre de recherche : Deux cas distincts livrés par un opérateur unique (l'auteur) :
- Cas 1 : Une plateforme d'évaluation de la protection multidimensionnelle pour 170 organisations nationales (conformité RGPD/OWASP). Livrée sur 17 semaines (~320 heures).
- Cas 2 : Un produit SaaS d'espace de travail d'analyse multi-locataire pour les analystes d'affaires (conformité RGPD + PCI DSS SAQ A). Livré en 31 jours calendaires (~165 heures).
Sources de données : L'étude a analysé l'historique complet du contrôle de version, les artefacts de gouvernance (packs de modules, prompts d'agents, listes de contrôle de revue) et le code source des deux systèmes.
Stratégie d'évaluation : Le cadre a été évalué selon six mesures opérationnelles calculées à partir des registres de livraison. L'étude reconnaît des limites méthodologiques, notamment l'absence de groupes de contrôle pré-cadre appariés et le biais de l'opérateur unique, présentant les résultats comme des démonstrations de faisabilité plutôt que comme des affirmations causales statistiquement généralisables.

3. L'artefact conçu : Un cadre de livraison gouverné et prêt pour l'IA

La contribution centrale est un cadre qui réingénie les exigences, passant d'outils de communication à des instruments de contrôle exécutables. Il repose sur trois éléments conçus :

A. Le Modèle de Exigences Canonique

Le cadre remplace les documents disparates par un modèle canonique unique et versionné, $M(m, v)$ , pour tout module $m$ à la base $v$ . Ce modèle contient :

R : Exigences et critères d'acceptation.
D : Décisions d'architecture et de conception.
C : Contraintes (métier, techniques, sécurité, accessibilité).
T : Cas de test et preuves de validation.
P : Provenance et relations de traçabilité.
A : État d'approbation et décideurs responsables.
H : Historique des versions et des changements.

Projections contrôlées : Les documents lisibles par l'humain (Packs d'assurance) et les fichiers lisibles par la machine (Packs d'agents) ne sont pas des sources de vérité distinctes. Ils sont générés comme des projections contrôlées, $O(i, m, v)$ , à partir du modèle canonique unique en utilisant des profils d'exportation spécifiques. Cela garantit que le document signé par une partie prenante et le code exécuté par un agent sont prouvablement cohérents.

B. Séparation des tâches via une boucle de double fournisseur

Pour appliquer le principe des « quatre yeux » aux agents autonomes, le cadre impose une boucle de construction et de revue par double fournisseur :

Agent de construction (Build Agent) : Un premier fournisseur d'IA (ex: Fournisseur A) est assigné pour générer le code et les artefacts d'implémentation.
Agent de revue (Review Agent) : Un second fournisseur d'IA indépendant (ex: Fournisseur B) effectue une revue indépendante, une validation de sécurité et une détection de défauts.
Porte humaine (Human Gate) : Des humains responsables valident chaque étape. L'agent de revue n'approuve pas la production ; il fournit des preuves aux décideurs humains.

C. La documentation comme surface de contrôle exécutable

Les exigences sont réingénierées pour être explicites, testables et traçables. Le cadre inclut des artefacts spécifiques tels que :

Pack de gouvernance de construction IA : Définit les limites, les actions prohibées et les règles de validation pour l'agent de construction.
Prompt/Contrat de réviseur indépendant : Un contrat gouverné pour l'agent de revue afin de valider par rapport à la base approuvée.
Manifeste de pack : Un enregistrement lisible par machine liant les fichiers générés à leur base d'origine, assurant la provenance et détectant la dérive.

Contrôle des changements : Si une exigence change, la proposition revient au modèle canonique. Après approbation, une nouvelle base ( $v+1$ ) est créée, et tous les outputs affectés (humains et machines) sont régénérés simultanément. Cela empêche la « dérive de spécification » où les documents humains et les instructions des agents divergent.

4. Résultats

Le cadre a été évalué à travers les deux cas en utilisant six mesures opérationnelles. Les résultats démontrent une cohérence à travers différents domaines, échelles et rythmes de livraison :

Mesure	Cas 1 (Plateforme de protection)	Cas 2 (SaaS d'espace de travail d'analyse)
Couverture de traçabilité	94,9 % (185/195 exigences)	97,8 % (496/507 exigences)
Divergence de sortie	0,5 divergence substantielle par base	0,0 divergence substantielle par base
Conformité à la base	99,2 % des activités contre la base actuelle	99,7 % des activités contre la base actuelle
Taux d'édition non autorisée	0,00 % (0/924 sorties)	0,00 % (0/343 sorties)
Taux d'échappement de défauts	9,1 % (31/341 défauts)	4,7 % (8/169 défauts)
Propagation des changements	Médiane 16 min	Médiane 0 min (commit unique)

Traçabilité : Une couverture élevée a été obtenue, la seule lacune systématique étant les liens de tests automatisés pour les fonctionnalités mineures de l'interface utilisateur.
Cohérence : L'approche de « projection contrôlée » a entraîné une divergence quasi nulle entre les artefacts humains et les agents.
Gouvernance : L'application structurelle du pipeline (ex: rejet des modifications locales non validées) a permis d'atteindre un taux de 0,00 % d'éditions non autorisées.
Défauts : Les taux d'échappement de défauts se situaient dans ou juste au-dessus des bandes de référence de l'industrie. Cependant, l'étude a noté que les défauts les plus persistants étaient des « échecs silencieux » (contrôles absents sans erreur visible) que la boucle interne rapide a manqués, ne faisant surface que lors de revues complètes délibérées du dépôt.

5. Signification et Revendications

Le document affirme fournir une architecture de gouvernance pour la livraison assistée par l'IA et une redéfinition correspondante du rôle de l'Analyste d'Affaires (BA).

Redéfinition du BA : Le BA n'est plus défini uniquement par ce qu'il écrit, mais par ce qu'il permet aux autres (humains et IA) de livrer. Le rôle passe de l'auteur de spécifications pour collègues à celui d'auteur d'instruments de contrôle pour des exécuteurs machines et de gouverneur du pipeline de livraison par l'IA.
Faisabilité de la Vitesse + Contrôle : L'étude démontre que l'ajout d'une gouvernance rigoureuse (séparation des tâches, traçabilité, contrôle de la base) ne nie pas l'avantage de vitesse de l'IA. Dans le Cas 2, le cadre a livré deux fois plus de modules en un quart du temps du Cas 1 tout en maintenant une conformité plus élevée et zéro édition non autorisée.
Source unique de vérité : Le papier valide qu'un modèle canonique unique peut servir à la fois l'assurance humaine et l'exécution machine sans créer de sources de vérité divergentes, à condition que les sorties soient générées comme des projections contrôlées.

Modestie des revendications :
Le papier stipule explicitement que ces résultats sont des démonstrations de faisabilité issues d'une étude de cas par un opérateur unique. Il ne revendique pas de généralisation statistique. Les auteurs reconnaissent que l'évaluation manque de contrôles pré-cadre appariés et que la métrique de « l'échappement de défauts » repose sur le jugement de l'auteur. La contribution primaire est la conception d'une méthode qui rend la livraison assistée par l'IA gouvernable, sûre et traçable, déplaçant la charge de la clartité de l'interprète humain vers l'artefact d'exigence structuré.