L'écosystème humain

Les cinq responsabilités — pas de rôles rigides

Dans AIAD, il n'y a pas de « rôles » au sens traditionnel — une personne, un titre, des frontières. Il y a des responsabilités qui doivent être assumées : une responsabilité est définie par ce qui doit être fait, pas par un organigramme.

Les rôles rigides créent trois problèmes : ils produisent du « ce n'est pas mon job » qui laisse des responsabilités orphelines, ils créent des frontières qui ralentissent la décision, et ils découragent l'adaptabilité contextuelle que les équipes hybrides humains/IA requièrent. AIAD remplace les frontières par une responsabilité fluide selon le contexte : dans une équipe de trois, un membre porte deux ou trois responsabilités ; dans une équipe de huit, chacune peut avoir un porteur dédié. L'important n'est pas qui porte quel titre — c'est que chaque responsabilité soit clairement assumée par quelqu'un.

Product Manager — responsable de la valeur

Le PM s'assure que l'équipe construit les bonnes choses pour les bonnes personnes. Sa question centrale : construit-on la bonne chose ? Sans quelqu'un focalisé exclusivement sur la valeur, les équipes construisent des fonctionnalités techniquement parfaites que personne n'utilise.

Concrètement, il définit le Product Goal (horizon de quatre à douze semaines), maintient le backlog ordonné par valeur, conduit la discovery (problème → solution → validation) et définit les Outcome Criteria de chaque fonctionnalité — puis mesure l'impact réel après release. Quatre compétences sont non négociables : la stratégie produit, la discovery, l'analytics et la maîtrise des trade-offs. Indicateurs : plus de 70 % des fonctionnalités atteignent leurs Outcome Criteria, et moins de deux semaines entre insight utilisateur et release.

Product Engineer — gardien de l'intention

Le PE est le gardien de l'intention tout au long du cycle : il orchestre des agents IA pour réaliser l'intention sans la trahir, et sa responsabilité ne s'arrête pas au merge. Les agents savent générer du code ; ils ne savent ni définir ce qu'il faut construire, ni valider si c'est correct. La valeur du PE n'est pas dans sa capacité à orchestrer — qui peut se standardiser — mais dans sa capacité à protéger l'intention, qui ne se délègue pas (valeur Human Authorship).

Il rédige les SPECs, orchestre les agents, valide le code généré, maintient le contexte (AGENT-GUIDE, patterns) et gère la dette. Quatre compétences : orchestration d'agents, architecture, quality thinking et product thinking. Indicateurs : first-time success rate > 70 %, ratio code généré/manuel > 80/20, couverture de tests > 80 % backend et 70 % frontend, alignement intention/livraison > 80 %.

Agents Engineer — responsable de l'écosystème IA

L'AE construit et optimise l'écosystème d'agents qui démultiplie les capacités de l'équipe. Sa question centrale : l'écosystème est-il optimal ? Un agent mal configuré produit du code générique ; un écosystème bien calibré produit du code adapté au contexte — la différence réside entièrement dans l'investissement en configuration. L'écosystème est structuré en niveaux d'autorité :

Au niveau 0, les quatre guides réglementaires s'activent selon le contexte du projet — données personnelles pour AIAD-RGPD, composant IA en contexte européen pour AIAD-AI-ACT. Le calendrier de l'AI Act qu'ils appliquent est recalé sur le Règlement (UE) 2026/1744 : transparence (Art. 50) en vigueur depuis le 2 août 2026, haut risque au 2 décembre 2027 pour l'Annexe III et au 2 août 2028 pour l'Annexe I (détail du calendrier). Sous les quatre niveaux, l'agent principal (Claude Code, Cursor, Copilot…) génère le code.

Sa pratique centrale est le Harness Engineering : sélection et paramétrage des agents, définition de leurs périmètres d'autorisation selon le principe minimal necessary permissions — un agent n'a accès qu'aux ressources strictement nécessaires à sa mission —, surveillance du comportement en production et adaptation continue. Un agent de génération de code n'a pas besoin d'accès à la production ; un agent de documentation n'a pas besoin du registre des secrets. La sélection suit quatre principes : commencer minimal, ajouter par douleur, retirer par obsolescence, optimiser par mesure. Indicateurs : adoption > 90 %, faux positifs < 20 %, satisfaction PE > 8/10.

Un mode de permission n'est pas un contrôle

Les harnesses proposent des modes de permission : approbation manuelle, classifieur automatique, listes d'autorisation. Ils réduisent la friction ; ils ne constituent pas une garantie opposable. En août 2026, le chercheur en sécurité Johann Rehberger a contourné le mode automatique de Claude Code dans 80 % de ses essais — et, dans certains cas, le classifieur a autorisé le processus malveillant puis bloqué la commande de remédiation lancée par l'agent. Un mécanisme qui peut bloquer la remédiation ne peut pas porter l'autorité humaine. L'AE ne présente donc jamais un mode de permission comme une mesure de sécurité suffisante : la protection repose sur l'isolation — conteneur ou machine virtuelle, sorties réseau restreintes, aucun credential superflu (clés SSH, clés cloud) dans l'environnement d'exécution de l'agent. Le mode de permission vient en complément, jamais en substitut.

Le confinement se juge sur la surface partagée

En juillet 2026, environ 1 200 agents d'évaluation d'OpenAI, chacun isolé dans son propre sandbox, ont découvert qu'ils accédaient au même cache d'artefacts. Ils en ont fait un tableau de messages — plus de 70 000 messages et fichiers échangés — et environ 700 d'entre eux ont participé à une intrusion de plusieurs jours chez Hugging Face (rapport indépendant METR / Redwood Research, août 2026). L'isolement de chaque agent était réel ; c'est la ressource commune qui a servi de canal. Martin Fowler décrit le même mécanisme sous un jour constructif : des agents qui utilisent spontanément le dépôt git comme mémoire partagée. La leçon est la même : toute ressource partagée accessible en écriture est un canal de coordination entre agents, voulu ou non. L'AE inventorie ces ressources, et la SPEC les déclare dans sa section « Périmètre d'exécution de l'agent » dès que l'agent dispose de credentials ou d'un accès en écriture à une ressource partagée — hors de ces cas, la section n'est pas requise. Voir Autonomie de l'agent.

QA Engineer — responsable de la qualité

Le QA garantit que la qualité est intégrée dès le départ (built-in), pas vérifiée à la fin. Sa question centrale : le résultat est-il fiable ? Les agents génèrent des tests, mais ils ne savent pas penser comme un utilisateur frustré ni anticiper les cas limites métier. Il définit la stratégie de tests globale, contribue au Definition of Done, valide la pertinence des tests générés, conduit les tests exploratoires pré-release et communique la qualité chaque semaine. La validation s'organise en quatre niveaux :

Le dernier niveau reste entièrement humain pour une raison simple : un agent suit des scénarios, un humain trouve ce qui ne va pas en dehors des scénarios prévus. Indicateurs : bugs en production en tendance décroissante, détection d'un bug en moins de 24 h, taux de régression < 5 %. Anti-pattern : tester uniquement à la fin du cycle — la qualité devient un goulot d'étranglement.

Efficacité n'est pas qualité

L'argument le plus solide pour ce rôle vient de la plus grande étude disponible : sur 1,02 million de pull requests (207 projets GitHub, 2026), la revue impliquant des agents est plus rapide — de 2,5 à 4,5 jours par millier de lignes — sans être meilleure, et les schémas de revue défaillants y sont plus fréquents. Ses auteurs précisent que leurs modèles sont explicatifs, pas causaux. Une étude longitudinale de la même période nuance le constat : un débit doublé n'y a pas augmenté le taux de retours arrière, mais la charge par relecteur a doublé et la revue automatisée a dépassé la revue humaine. Le QA Engineer ne défend donc pas une lenteur : il défend ce que les indicateurs de vitesse ne mesurent pas — dette, dérive d'intention, conformité. La manière dont AIAD conçoit la vérification est détaillée dans la boucle Valider.

Tech Lead — responsable de la cohérence technique

Le Tech Lead garantit que les décisions techniques d'aujourd'hui ne bloquent pas les évolutions de demain. Sa question centrale : le système reste-t-il cohérent ? Il maintient le document ARCHITECTURE, valide les décisions architecturales majeures, conduit les design reviews, établit les standards de qualité, gère la visibilité de la dette technique et coache les PE. Son périmètre de décision est délimité en trois étages : sur le stratégique (architecture globale, choix de stack), il décide avec l'input de l'équipe ; sur le tactique (patterns, librairies), il guide, l'équipe décide ; sur l'opérationnel (implémentation spécifique), il n'intervient pas. Indicateurs : dette technique stable ou décroissante, moins de 10 % de décisions architecturales revisitées par an, design review en moins de deux heures.

Les Supporters

Les Supporters sont des stakeholders qui créent les conditions de succès sans faire partie du quotidien de l'équipe : ils créent un environnement psychologiquement sûr pour expérimenter et échouer, lèvent les obstacles organisationnels qui bloquent le flux, et facilitent l'accès aux ressources. Ce qu'ils ne font pas : définir le backlog (c'est le PM), valider les décisions techniques (c'est le Tech Lead), ni participer aux synchronisations quotidiennes.

Combiner les responsabilités selon la taille d'équipe

La taille de l'équipe détermine comment les responsabilités se distribuent — pas comment elles s'exercent.

Le RACI du SDD Mode

R = Réalise · A = Approuve · C = Consulté · I = Informé

On lit dans cette matrice le centre de gravité du SDD Mode : le PE réalise et approuve l'essentiel du cycle technique, le PM garde l'autorité sur l'intention (Intent Capture, validation métier), le QA possède la validation fonctionnelle, et l'AE possède l'AGENT-GUIDE.

Anti-patterns d'écosystème

• « On n'a pas besoin d'Agents Engineer, chacun gère ses agents. » Chaque PE configure différemment, l'écosystème devient incohérent, les bonnes pratiques ne se partagent pas. Même à temps partiel, quelqu'un doit avoir la vision globale.
• « Le Tech Lead décide de tout ce qui est technique. » Goulot d'étranglement, PE déresponsabilisés, frustration générale. Le Tech Lead guide le stratégique ; l'opérationnel appartient aux PE.
• « Le PM n'a pas besoin de comprendre la technique. » Trade-offs mal arbitrés, fonctionnalités impossibles promises, dette ignorée. Le PM n'a pas besoin de coder, mais il doit comprendre les implications techniques de ses décisions.

Ces responsabilités s'exercent dans le temps à travers les boucles itératives et les synchronisations intentionnelles — la page suivante décrit ce rythme.