L'Écosystème AIAD — Les Cinq Responsabilités

Définition

Dans AIAD, il n’y a pas de “rôles” au sens traditionnel — une personne, un titre, des frontières rigides. 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. Dans une équipe de trois personnes, un membre peut assumer deux ou trois responsabilités simultanément. Dans une équipe de huit, chaque responsabilité 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.

Pourquoi cette approche existe

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 prise de décision. Et ils découragent l’adaptabilité contextuelle que les équipes hybrides humains/IA requièrent. AIAD remplace les frontières rigides par une responsabilité fluide selon le contexte.

Product Manager — Responsable de la Valeur

Définition. Le Product Manager s’assure que l’équipe construit les bonnes choses pour les bonnes personnes. Sa question centrale : construit-on la bonne chose ?

Pourquoi cette responsabilité existe. Sans quelqu’un focalisé exclusivement sur la valeur, les équipes construisent des fonctionnalités techniquement parfaites que personne n’utilise. Le PM est le gardien des outcomes.

Comment. Le PM définit le Product Goal (horizon de quatre à douze semaines) mensuellement, maintient le backlog ordonné par valeur en continu, conduit la discovery (problème → solution → validation) hebdomadairement, et définit les Outcome Criteria de chaque fonctionnalité. Après chaque release, il mesure l’impact réel.

Quatre compétences sont non-négociables : la stratégie produit (savoir où on va et pourquoi), la discovery (identifier le vrai problème avant de construire), l’analytics (mesurer ce qui compte, décider sur des données), et la maîtrise des trade-offs (arbitrer entre court et long terme).

Les indicateurs de succès : plus de 70 % des fonctionnalités atteignent leurs Outcome Criteria, et le délai entre insight utilisateur et release est inférieur à deux semaines.

Anti-pattern. Le PM “passe-plat” qui transmet les demandes des stakeholders sans les challenger ni les prioriser. Il n’est pas un secrétaire de la direction — il est responsable de la valeur.

Product Engineer — Gardien de l’Intention

Définition. Le Product Engineer est le gardien de l’intention tout au long du cycle de développement. Il orchestre des agents IA pour réaliser l’intention sans la trahir. Sa responsabilité ne s’arrête pas au merge — il veille à ce que l’intention reste intacte tout au long du processus, y compris après la livraison.

Pourquoi cette responsabilité existe. Les agents IA savent générer du code. Ils ne savent pas définir ce qu’il faut construire ni valider si c’est correct. Le PE fait le pont. Sa valeur n’est pas dans sa capacité à orchestrer — qui peut se standardiser — mais dans sa capacité à protéger l’intention, qui ne peut pas être déléguée.

Ancrage constitutionnel : Valeur 1 (Primauté de l’Intention Humaine), Article II (Human Authorship), Article III (Vision des Ruptures).

Comment. Le PE rédige des spécifications techniques précises (par fonctionnalité), orchestre les agents pour générer le code (quotidiennement), valide la qualité du code généré (post-génération), maintient le contexte (AGENT-GUIDE, patterns) en continu, et gère la dette technique.

Quatre compétences sont non-négociables : l’orchestration d’agents (formuler des intentions claires, structurer le contexte), l’architecture (penser système, anticiper les implications), le quality thinking (définir “Done”, penser aux cas limites), et le product thinking (comprendre le pourquoi, pas juste le comment).

Les indicateurs de succès : first-time success rate supérieur à 70 %, ratio code généré/manuel supérieur à 80/20, couverture de tests supérieure à 80 % backend et 70 % frontend, et taux d’alignement intention/livraison supérieur à 80 % (évalué lors de l’Atelier d’Intention).

Anti-pattern. Le PE qui réécrit systématiquement le code des agents au lieu d’améliorer ses spécifications et son contexte. Ce comportement est le symptôme d’un problème en amont, pas une solution.

Agents Engineer — Responsable de l’Écosystème IA

Définition. L’Agents Engineer 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 ?

Pourquoi cette responsabilité existe. 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.

Comment. L’AE sélectionne les agents pertinents (mensuellement), les configure et calibre (initialement, puis de façon itérative), définit la gouvernance (supervision, validation) à l’initialisation, forme l’équipe à l’utilisation efficace en continu, monitore les performances hebdomadairement, et expérimente avec de nouveaux agents chaque mois.

Gouvernance Réglementaire — Niveau 0 (v1.5)

L’écosystème d’agents est structuré en niveaux d’autorité. Au Niveau 0, la Gouvernance Réglementaire : les AGENT-GUIdes réglementaires injectés dans chaque session de développement impliquant un domaine régulé. Ces guides ont un droit de veto absolu sur tout code non conforme.

AGENT-GUIDE	Référentiel	Scope
AIAD-AI-ACT	Règlement (UE) 2024/1689 — EU AI Act	Classification risque, obligations par niveau, calendrier d’application (complète le 2 août 2026)
AIAD-RGPD	RGPD (UE) 2016/679	Privacy by Design, minimisation données, bases légales, droits des personnes
AIAD-RGAA	RGAA 4.1 / WCAG 2.1	Accessibilité numérique, obligations légales françaises
AIAD-RGESN	RGESN	Écoconception de services numériques, sobriété computationnelle

Ces guides s’activent selon le contexte du projet : un projet traitant des données personnelles active AIAD-RGPD ; un projet impliquant un composant IA en contexte européen active AIAD-AI-ACT. Le principe Human Authorship constitue une réponse directe aux exigences de supervision humaine imposées par l’AI Act pour les systèmes à haut risque.

Les autres niveaux de gouvernance

Au Niveau 1, la Gouvernance (sécurité, conformité, architecture) : droit de veto sur le code généré. Au Niveau 2, la Qualité (tests, code review, performance) : avertissements et recommandations. Au Niveau 3, la Productivité (documentation, refactoring, migration) : suggestions d’amélioration. À la base, l’Agent Principal (Claude Code, Cursor, Copilot) : génération de code.

La sélection suit quatre principes : commencer minimal (agent principal + sécurité + qualité), ajouter par douleur (un problème récurrent justifie un nouvel agent), retirer par obsolescence (un agent non utilisé depuis un mois est supprimé), et optimiser par mesure (suivre l’usage et l’efficacité réelle).

Les indicateurs de succès : taux d’adoption supérieur à 90 %, taux de faux positifs inférieur à 20 %, satisfaction PE sur l’écosystème supérieure à 8/10.

Harness Engineering — La pratique centrale de l’AE (v1.6)

Le terme “Harness Engineering” désigne l’ensemble des pratiques de configuration, supervision et gouvernance des agents IA que l’AE met en œuvre. Il couvre : la sélection et le paramétrage des agents, la définition de leurs périmètres d’autorisation (minimal necessary permissions — un agent n’a accès qu’aux ressources strictement nécessaires à sa mission), la surveillance de leur comportement en production, et l’adaptation continue de l’écosystème. Ce vocabulaire est convergent avec les pratiques de l’industrie (Thoughtworks Radar 2026) et positionne l’AE comme un métier à part entière.

La gouvernance sécurité des agents est une dimension non-négociable du Harness Engineering : chaque agent configuré dans l’écosystème AIAD doit opérer selon le principe de moindre privilège. Un agent de génération de code n’a pas besoin d’accès aux systèmes de production. Un agent de documentation n’a pas besoin d’accès au registre des secrets. Cette gouvernance est le pendant technique de la valeur Human Authorship : on ne délègue pas la supervision des accès critiques à l’agent.

Ancrage constitutionnel : Valeur 7 (Human Authorship) — la gouvernance sécurité des agents est l’expression technique du principe de supervision humaine, convergente avec les exigences de l’AI Act (Art. 14).

Anti-pattern. L’AE qui accumule des agents “au cas où” sans mesurer leur utilité réelle, ou qui configure des agents avec des permissions larges “pour simplifier”. Plus d’agents ne signifie pas plus d’efficacité — et des permissions non restreintes sont un risque de gouvernance.

QA Engineer — Responsable de la Qualité

Définition. Le QA Engineer garantit que la qualité est intégrée dès le départ, pas vérifiée à la fin. Sa question centrale : le résultat est-il fiable ?

Pourquoi cette responsabilité existe. Les agents génèrent des tests, mais ils ne savent pas penser comme un utilisateur frustré ni anticiper les cas limites métier. La qualité built-in requiert une intelligence humaine que l’agent ne peut pas remplacer.

Comment. Le QA définit la stratégie de tests globale (initialement, puis revue trimestrielle), contribue au Definition of Done par fonctionnalité, valide la pertinence des tests générés post-génération, conduit les tests exploratoires pré-release, et mesure et communique la qualité hebdomadairement.

La validation s’organise en quatre niveaux :

Niveau	Responsable	Automatisation
Tests unitaires	Agents IA + PE	100 % automatisés
Tests d’intégration	PE + Agent Quality	90 % automatisés
Tests fonctionnels	QA + Agent Quality	70 % automatisés
Tests exploratoires	QA humain	0 % automatisés

Le dernier niveau reste 100 % 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.

Les indicateurs de succès : bugs en production en tendance décroissante, temps de détection d’un bug inférieur à 24 h, taux de régression inférieur à 5 %.

Anti-pattern. Le QA qui teste uniquement à la fin du cycle au lieu de contribuer à la définition de “Done” dès le départ. Cette pratique transforme la qualité en goulot d’étranglement.

Tech Lead — Responsable de la Cohérence Technique

Définition. 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 ?

Pourquoi cette responsabilité existe. Sans vision technique long-terme, chaque fonctionnalité est optimisée localement mais le système global devient incohérent. La dette technique s’accumule invisiblement.

Comment. Le Tech Lead définit et maintient le document ARCHITECTURE, valide les décisions architecturales majeures à la demande, conduit les design reviews par fonctionnalité majeure, établit les standards de qualité à l’initialisation, gère la dette technique en continu (visibilité et priorisation), et coache les PE sur les sujets complexes.

Son périmètre de décision est clairement délimité :

Décisions stratégiques (architecture globale, choix de stack) : il décide avec l’input de l’équipe
Décisions tactiques (patterns, librairies) : il guide, l’équipe décide
Décisions opérationnelles (implémentation spécifique) : il n’intervient pas

Les indicateurs de succès : dette technique stable ou décroissante, décisions architecturales revisitées inférieures à 10 % par an, temps de design review inférieur à deux heures.

Anti-pattern. Le Tech Lead “super développeur” qui code plus qu’il ne guide, créant un goulot d’étranglement. Son rôle est de multiplier l’efficacité de l’équipe, pas de concentrer la production sur lui.

Les Supporters

Les Supporters sont des stakeholders qui créent les conditions de succès de l’équipe sans faire partie de son quotidien. Ils créent un environnement psychologiquement sûr pour que l’équipe ose expérimenter et échouer. Ils lèvent les obstacles organisationnels qui bloquent le flux. Ils 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), participer aux synchronisations quotidiennes.

Combiner les responsabilités

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

Équipe de 2-3 personnes : une personne assume typiquement PM et Tech Lead, une autre PE, QA et AE.
Équipe de 4-6 personnes : PM, QA et AE peuvent être portés par des personnes distinctes, avec des PE qui doublent sur Tech Lead et AE.
Au-delà de 7 personnes : chaque responsabilité peut avoir un porteur dédié.

La règle d’or : quelle que soit la taille de l’équipe, chaque responsabilité doit avoir un porteur clairement identifié.

Anti-patterns d’écosystème

“On n’a pas besoin d’Agents Engineer, chacun gère ses agents.” Résultat : 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.” Résultat : goulot d’étranglement, PE déresponsabilisés, frustration générale. Le Tech Lead guide les décisions stratégiques. Les décisions opérationnelles appartiennent aux PE.

“Le PM n’a pas besoin de comprendre la technique.” Résultat : trade-offs mal arbitrés, fonctionnalités impossibles promises, dette technique ignorée. Le PM n’a pas besoin de coder, mais il doit comprendre les implications techniques de ses décisions.