Concevoir un harnais agentique

0Évolutions de la version 3

Cette version corrige les incohérences internes de la V2 et comble les manques identifiés lors de la relecture critique. Chaque changement est signalé dans le corps du document par un encadré V3.

Corrections d'incohérences (V2 → V3)

Compléments apportés

1Objectif et vision

Ce document est la version de référence du harnais agentique : il couvre l'intégralité du cycle de vie d'un projet informatique, du cadrage initial jusqu'au décommissionnement, en passant par le design, la réalisation, le déploiement et l'exploitation. Il sert de fil conducteur pour la mise en œuvre : toute personne qui construit ou fait évoluer ce harnais peut s'y référer pour savoir quelles phases couvrir, quels artefacts produire, quels référentiels respecter, et à quel moment un humain doit trancher.

Trois ajouts distinguaient la V2 de la V1 : la couverture du design (artefacts UX/UI), la couverture de l'exploitation et de la maintenance après la mise en production, et la couverture du décommissionnement (fin de vie, données à archiver ou détruire, accès à désactiver, obligations légales). Un principe transversal complétait ces ajouts : chaque famille d'artefacts doit être produite en respectant des référentiels reconnus plutôt que des conventions ad hoc, pour que la qualité produite par les agents soit vérifiable par un tiers plutôt que seulement plausible.

2Cadre de référence du cycle de vie

Le découpage retenu s'inspire des grandes familles de processus définies par la norme ISO/IEC/IEEE 12207 relative aux processus du cycle de vie du logiciel (développement, exploitation, maintenance et retrait), adaptées et complétées pour refléter la pratique courante des projets numériques : ajout d'une phase de design distincte de la conception technique, et détail des artefacts de gouvernance transverses.

Neuf phases structurent ainsi le document : Cadrage Design Conception technique Planification Réalisation Vérification Déploiement Exploitation & maintenance Décommissionnement. Une dixième catégorie, Transverse, regroupe les artefacts qui traversent toutes les phases plutôt que d'appartenir à une seule.

Chaque phase est portée par un ou plusieurs agents spécialisés et se termine par un point de contrôle humain — voir la liste canonique en section 8.

3Panorama des artefacts à couvrir

Un projet informatique produit des artefacts à chaque phase de son cycle de vie, y compris après sa mise en production. Le harnais doit couvrir l'ensemble de ce cycle plutôt qu'une phase isolée, car la valeur du système vient largement de la cohérence qu'il maintient entre artefacts en amont et en aval — cadrage jusqu'à décommissionnement compris.

3.1 Cadrage

• Note d'opportunité et objectifs métier
• Cahier des charges (besoins, contraintes, périmètre)
• Analyse des risques et des parties prenantes
• Estimation budgétaire et calendaire de premier niveau

3.2 Design (UX/UI)

• Personas et parcours utilisateurs
• Wireframes et maquettes basse puis haute fidélité
• Prototype interactif
• Charte graphique et design system (composants réutilisables)
• Guide d'accessibilité (conformité RGAA/WCAG)
• Protocole et résultats des tests d'utilisabilité

3.3 Conception technique

• Spécifications fonctionnelles
• Spécifications techniques
• Architecture logicielle (diagrammes de composants, de séquence, de déploiement)
• Décisions d'architecture documentées (ADR — Architecture Decision Records)
• Modèle de données
• Choix technologiques et justification

3.4 Planification

• Backlog produit et user stories
• Découpage en lots ou sprints
• Planning et jalons

3.5 Réalisation

• Code source et configuration d'environnement
• README et documentation d'installation
• Conventions de code et structure du dépôt

3.6 Vérification

• Plan de tests
• Tests unitaires, d'intégration et de bout en bout
• Rapports de couverture
• Revue de sécurité, de conformité et d'accessibilité

3.7 Déploiement

• Pipeline d'intégration et de livraison continues (CI/CD)
• Scripts d'infrastructure as code
• Documentation d'exploitation (runbook) et plan de reprise d'activité

3.8 Exploitation et maintenance

• Plan de maintenance (corrective, évolutive, préventive)
• Journal des incidents et post-mortems
• Notes de version et changelog
• Registre de dette technique
• Tableau de bord de supervision (monitoring, alerting, indicateurs SLO/SLI)
• Plan de gestion des correctifs de sécurité (patch management)
• Rapports d'audit périodiques (sécurité, performance, conformité)

3.9 Décommissionnement

• Plan de décommissionnement (calendrier, dépendances, communication aux utilisateurs)
• Plan de migration, d'export et d'archivage des données
• Procédure de désactivation sécurisée des accès et des services
• Preuve de destruction ou d'anonymisation des données (conformité RGPD)
• Bilan de fin de vie et capitalisation (retour d'expérience, leçons apprises)

3.10 Transverse

• Documentation utilisateur
• Plan de gestion de projet et comptes-rendus
• Matrice de traçabilité exigences ↔ tests
• Registre des décisions et glossaire du projet

4Référentiels et bonnes pratiques par famille d'artefacts

Produire un artefact ne suffit pas : encore faut-il qu'il respecte des règles reconnues plutôt que des conventions inventées au fil de l'eau par chaque agent. Le tableau suivant associe à chaque famille d'artefacts un ou plusieurs référentiels que les agents doivent connaître et appliquer — soit en les citant explicitement dans l'artefact produit (un ADR par décision d'architecture, par exemple), soit en les utilisant comme grille d'auto-évaluation avant de marquer l'artefact prêt pour validation humaine. Cette exigence doit être injectée directement dans le prompt de chaque agent spécialisé, pas laissée à l'appréciation implicite du modèle.

5Principes d'architecture

Huit principes structurent une architecture agnostique capable de tenir dans la durée, indépendamment du framework choisi pour l'implémenter.

1. Le registre d'artefacts comme source de vérité unique. Chaque artefact généré (document ou code) est enregistré dans un registre central avec ses métadonnées : type, version, statut (brouillon, en revue, validé — voir annexe A), auteur (agent ou humain), et liens vers les artefacts dont il dépend. Aucun agent ne doit maintenir sa propre copie parallèle de l'état du projet.
2. Des agents spécialisés par type d'artefact plutôt qu'un agent généraliste unique. Un agent « Design » n'a pas les mêmes besoins en outils, en style de sortie ni en critères de qualité qu'un agent « Code » ou « Exploitation ». La spécialisation permet des instructions plus précises, une évaluation plus simple, et la possibilité de faire évoluer un agent sans affecter les autres.
3. Des contrats de dépendance explicites entre artefacts. Les spécifications dérivent du cahier des charges, l'architecture dérive des spécifications, le code dérive de l'architecture et des user stories, les tests dérivent des spécifications et du code. Ces dépendances doivent être déclarées formellement dans le registre afin que toute modification amont déclenche une alerte ou une régénération des artefacts avals concernés.
4. Une boucle agentique générique par agent. Chaque agent spécialisé suit le même cycle : lecture du contexte et des artefacts dont il dépend, planification, génération, auto-vérification (cohérence, complétude, conformité au référentiel applicable), puis publication dans le registre.
5. Des points de contrôle humains aux transitions critiques. Certaines transitions (validation du cahier des charges, validation de l'architecture, découpage du backlog, mise en production, décommissionnement) doivent rester des décisions humaines explicites. Le harnais doit pouvoir suspendre le flux à ces points et reprendre après validation.
6. Des garde-fous de qualité systématiques. Revue croisée entre agents, linters et analyseurs statiques pour le code, exécution effective des tests générés, vérification de cohérence terminologique entre documents. Un artefact qui n'a pas passé ces contrôles ne doit pas être marqué « validé » dans le registre.
7. La conformité aux référentiels comme critère de qualité systématique. Chaque agent spécialisé doit connaître le ou les référentiels applicables à son artefact (section 4) et les utiliser comme grille d'auto-vérification avant publication — un artefact qui ignore le référentiel qui lui est associé ne doit pas être considéré comme complet, même s'il est par ailleurs bien écrit.
8. Une couverture du cycle de vie qui ne s'arrête pas à la mise en production. Le registre et les points de contrôle humains doivent rester actifs après le déploiement : les artefacts d'exploitation (supervision, incidents, dette technique) et de décommissionnement font partie du même registre que les artefacts de conception, avec les mêmes exigences de traçabilité — un système n'est pas « terminé » au sens du harnais tant qu'il n'a pas été décommissionné ou repris par un dispositif équivalent.

6Architecture proposée

L'architecture s'organise en quatre macro-phases : cadrage & conception, réalisation & vérification, déploiement & exploitation, et fin de vie — complétées par le transverse. Elle reste indépendante du framework : orchestrateur, registre, agents, outils et référentiels sont des rôles fonctionnels que l'on peut implémenter avec n'importe quelle pile technique.

6.1 Composants

• Orchestrateur central. Reçoit la demande initiale, détermine la séquence de génération en fonction des dépendances déclarées, distribue le travail aux agents spécialisés, et gère les reprises en cas d'échec ou de modification amont — y compris en phase d'exploitation, où son rôle devient plus cyclique que linéaire. Il est également responsable de l'arbitrage de premier niveau entre agents et de la production des artefacts mécaniques (matrice de traçabilité, registre des décisions).
• Registre d'artefacts. Base d'état versionnée qui stocke chaque artefact, son statut, ses dépendances et son historique, du cadrage au décommissionnement. C'est la mémoire persistante et partagée du projet — elle doit survivre à l'arrêt et au redémarrage du harnais, et rester consultable même après la clôture du système qu'elle documente. Ses exigences de sécurité et de sauvegarde sont détaillées en annexe B.
• Référentiels de bonnes pratiques. Base de référence (ADR, C4, WCAG/RGAA, 12-factor, ITIL, ISO 25010, RGPD, SRE…) que les agents consultent pour produire des artefacts conformes plutôt que plausibles. Voir la section 4 pour le détail par famille d'artefacts. configurable
• Agents spécialisés. Onze agents répartis en quatre macro-phases, plus le transverse : Cadrage Design UX/UI Spécifications Architecture Backlog pour l'amont ; Code Tests pour la réalisation ; Déploiement Exploitation/Maintenance pour la mise en production et son suivi ; Décommissionnement pour la fin de vie ; Documentation en transverse. Chacun est instruit avec un contexte, des outils et des référentiels propres à son artefact (principe de moindre privilège).
• Couche d'outils. Accès aux fichiers, exécution de code, recherche d'information, génération de documents bureautiques, interaction avec un dépôt de code. Les agents ne doivent avoir accès qu'aux outils nécessaires à leur artefact.
• Points de contrôle humains. Interface — même minimale — permettant à un humain d'approuver, rejeter ou amender un artefact avant que le flux ne se poursuive. En exploitation, ces points deviennent périodiques plutôt que ponctuels ; au décommissionnement, ils impliquent typiquement plus d'une personne (sponsor et référent protection des données). La liste canonique des dix points de contrôle figure en section 8.

7Flux de génération

Exemple de déroulé pour un projet standard, illustrant l'articulation entre génération automatique et validation humaine, de la demande initiale à la mise en production :

1. Le porteur de projet formule sa demande initiale (objectifs, contraintes, périmètre pressenti).
2. L'agent Cadrage produit une note d'opportunité et un cahier des charges ; point de contrôle humain avant de poursuivre.
3. Les agents Design, Spécifications et Architecture travaillent à partir du cahier des charges validé, puis se recoupent pour vérifier leur cohérence mutuelle (le design correspond-il aux exigences fonctionnelles, le modèle de données correspond-il aux deux).
4. L'agent Backlog découpe les artefacts validés en user stories et propose un planning ; point de contrôle humain sur le découpage et les priorités.
5. L'agent Code génère l'implémentation par lot ; l'agent Tests génère en parallèle les tests correspondants et les exécute réellement. revue de code
6. L'agent Déploiement produit le pipeline CI/CD et la documentation d'exploitation une fois le code stabilisé ; l'agent Documentation produit les guides utilisateur (cadre Diátaxis).
7. Point de contrôle humain final avant mise en production.

Ce flux initial se termine à la mise en production, mais le harnais ne s'arrête pas là. Deux flux supplémentaires prennent le relais.

• Flux d'exploitation (cyclique). Une fois en production, l'agent Exploitation/Maintenance opère en boucle continue plutôt qu'en séquence à sens unique : il met à jour le tableau de bord de supervision, consigne les incidents et leurs post-mortems, tient le registre de dette technique, et déclenche des points de contrôle humains périodiques plutôt qu'un point de contrôle unique. Ce flux dure généralement bien plus longtemps que le flux de construction initial.
• Flux de décommissionnement (terminal). Déclenché par une décision humaine explicite (fin de contrat, remplacement par un autre système, arrêt d'activité), il mobilise l'agent Décommissionnement, qui produit le plan de fin de vie, orchestre l'archivage ou la destruction des données, et documente le bilan de capitalisation. Ce flux se termine par la clôture des artefacts correspondants dans le registre plutôt que par leur suppression : la trace du projet doit rester consultable même après l'arrêt du système lui-même.

À chaque étape, une modification déclenchée en amont doit se propager automatiquement aux artefacts avals concernés, via les dépendances déclarées dans le registre — c'est le mécanisme qui évite la dérive documentaire, l'un des risques principaux de ce type de système.

7.1 Résolution de conflits entre agents

1. Revue croisée automatique : chaque agent confronte son artefact aux dépendances déclarées et signale les écarts dans le registre.
2. Arbitrage de l'orchestrateur : si un écart est détecté, l'orchestrateur demande aux agents concernés une régénération ciblée avec un contexte enrichi (les deux artefacts contradictoires).
3. Escalade humaine : si le désaccord persiste après deux régénérations, l'orchestrateur suspend le flux et soumet le conflit au point de contrôle humain de la phase concernée avec une synthèse des options.

7.2 Gestion des échecs

1. Nouvel essai (retry) : échec technique ou sortie inexploitable — l'orchestrateur relance le même agent avec le même contexte (nombre maximal d'essais configurable, défaut : 2).
2. Régénération avec contexte enrichi : échec qualitatif (garde-fous non passés) — l'agent relance avec les retours détaillés des vérifications (linters, tests, revue croisée).
3. Escalade humaine : échec persistant ou conflit non résolu — le point de contrôle humain reçoit un rapport d'échec (artefacts, erreurs, essais effectués) et décide : corriger manuellement, reformuler la demande, ou annuler.

8Gouvernance et rôles

Le harnais automatise la production des artefacts, pas la décision. Une répartition claire des responsabilités entre agents et humains évite deux dérives symétriques : un système où l'humain valide sans vraiment lire (le point de contrôle devient une formalité), et un système où l'humain doit tout réécrire (le harnais n'apporte plus de valeur). La répartition suivante est une base à adapter au contexte de gouvernance de chaque organisation :

9Enjeux et bonnes pratiques

• Cohérence inter-artefacts. Le risque principal n'est pas qu'un agent produise un mauvais artefact isolé, mais que plusieurs artefacts dérivent silencieusement les uns par rapport aux autres. Les contrats de dépendance et les revues croisées entre agents sont la principale parade.
• Traçabilité et gestion du changement. Chaque artefact doit pouvoir être retracé jusqu'à sa source et chaque modification amont doit déclencher une analyse d'impact sur les artefacts avals, avec re-validation humaine si nécessaire.
• Fiabilité et vérifiabilité. Les agents de génération de code et de tests doivent être ancrés sur une exécution réelle (compilation, exécution des tests, linters) plutôt que sur une simple génération de texte plausible.
• Sécurité et confinement. L'exécution de code généré par les agents doit se faire dans un environnement isolé, avec des permissions limitées, en particulier pour les artefacts de déploiement et d'infrastructure.
• Coût et parallélisation. Certains artefacts peuvent être générés en parallèle, d'autres sont strictement séquentiels. L'orchestrateur doit exploiter le parallélisme possible sans casser les dépendances réelles — et rester sous le budget défini (voir section 10).
• La dette technique et l'obsolescence. Un système en exploitation accumule des écarts entre ce que le registre décrit et ce qui tourne réellement (correctifs d'urgence non documentés, dépendances obsolètes). Le registre de dette technique doit être un artefact de première classe, pas une note informelle, pour que cet écart reste mesurable plutôt que silencieux.
• La conformité en fin de vie. Le décommissionnement engage des obligations qui dépassent le strict cadre technique : durées légales de conservation de certaines données, droit à l'effacement, portabilité pour les utilisateurs concernés. Ces obligations doivent être vérifiées avant la destruction de tout artefact ou donnée, pas après.

10Indicateurs de pilotage et amélioration continue

Le harnais lui-même doit pouvoir être évalué, au même titre que les artefacts qu'il produit. Les indicateurs suivants, avec leurs cibles indicatives, suffisent à commencer :

10.1 Maîtrise des coûts

1. Budget par phase : le cadrage fixe une enveloppe en tokens par phase ; l'orchestrateur la consigne dans le registre et alerte en cas de dépassement.
2. Hiérarchie de modèles : modèles légers pour la génération de premier jet et les tâches répétitives ; modèles plus capables réservés aux artefacts critiques (architecture, spécifications, synthèses).
3. Limitation des régénérations : les budgets de retry (section 7.2) sont bornés pour éviter les boucles coûteuses ; l'escalade humaine est préférée à une régénération illimitée.
4. Parallélisation raisonnée : générer en parallèle les artefacts indépendants réduit le coût calendaire sans augmenter le coût total.

Le bilan de capitalisation produit lors d'un décommissionnement (section 3.9) ne devrait pas rester un document isolé : les leçons qui y sont consignées doivent alimenter les prompts des agents amont pour les projets suivants — c'est ce qui transforme une suite de projets ponctuels en un système qui s'améliore réellement dans la durée.

11Feuille de route de mise en œuvre

1. Définir le schéma du registre d'artefacts : types d'artefacts, métadonnées, statuts (annexe A), modèle de dépendances, et le fichier de configuration des référentiels (section 4).
2. Orchestrateur minimal avec les agents Cadrage, Spécifications et Architecture, et un point de contrôle humain (PC1).
3. Traçabilité complète et propagation des changements amont → aval, avec analyse d'impact.
4. Ajouter l'agent Design UX/UI (PC2) et l'agent Backlog (PC4), rattachés au registre au même titre que les autres artefacts de conception.
5. Étendre aux agents de réalisation (Code, Tests) avec exécution réelle et vérification automatique (PC5).
6. Ajouter les agents Déploiement et Documentation (PC6, PC9).
7. Ajouter l'agent Exploitation/Maintenance et le flux cyclique de supervision post mise en production (PC7).
8. Ajouter l'agent Décommissionnement et le flux terminal correspondant (PC8).
9. Industrialiser : parallélisation, observabilité, indicateurs de pilotage (section 10), boucle d'amélioration continue.

Cette progression permet de valider le mécanisme central — cohérence et traçabilité entre artefacts — sur un périmètre restreint avant de l'étendre à l'ensemble du cycle de vie, de la naissance à la fin de vie du système.

12Tableau de synthèse — fil conducteur

Vue d'ensemble à utiliser comme référence rapide lors de la mise en œuvre ou de l'audit du harnais.

13Glossaire

ADR (Architecture Decision Record)

Document court formalisant une décision d'architecture : contexte, décision, conséquences. Chaque décision structurante fait l'objet d'un ADR versionné dans le registre.

Agent (spécialisé)

Instance d'exécution autonome chargée d'une famille d'artefacts (ex. agent Code, agent Design). Suit une boucle générique : contexte → planification → génération → auto-vérification → publication.

Artefact

Production du harnais : document, code, configuration, jeu de tests, plan, preuve… Chaque artefact est enregistré dans le registre avec métadonnées, statut et dépendances.

Capitalisation

Processus de collecte des leçons d'un projet (bilan de fin de vie, post-mortems) et de leur réinjection dans les prompts des agents pour les projets suivants.

Contrat de dépendance

Déclaration formelle dans le registre reliant un artefact aval à ses artefacts amont (ex. le code dépend de l'architecture et des user stories). Toute modification amont déclenche alerte et régénération aval.

Décommissionnement

Phase terminale du cycle de vie : planification de la fin de service, archivage ou destruction des données, désactivation des accès, bilan de capitalisation.

Harnais agentique

Ensemble organisé (orchestrateur, registre, agents, outils, référentiels, points de contrôle) qui produit et maintient les artefacts d'un projet tout au long de son cycle de vie.

Orchestrateur

Composant central qui reçoit la demande, séquence la génération selon les dépendances, distribue le travail aux agents, gère les reprises, arbitre les conflits et produit les artefacts mécaniques (traçabilité, registre des décisions).

Point de contrôle humain (PC)

Moment où le flux s'interrompt pour une décision humaine explicite : approuver, rejeter ou amender un artefact. Liste canonique PC1 → PC10 (section 8).

Registre d'artefacts

Base d'état versionnée, source de vérité unique du projet : artefacts, statuts, versions, dépendances, historique. Doit survivre au harnais et rester consultable après la clôture du système.

Référentiel

Ensemble de règles reconnues (norme, standard, bonnes pratiques) associé à une famille d'artefacts et servant de grille d'auto-évaluation aux agents (WCAG, ADR, C4, 12-factor, ITIL, RGPD…).

Registre de dette technique

Artefact de première classe listant les écarts entre l'état documenté et l'état réel du système en exploitation (correctifs non documentés, dépendances obsolètes), pour les rendre mesurables.

SLO / SLI

Service Level Objective / Indicator : objectif de niveau de service (ex. disponibilité 99,9 %) mesuré par des indicateurs (SLI) — pratique SRE appliquée à la supervision.

Système (produit)

Le logiciel ou service final que le harnais aide à concevoir, construire, exploiter et décommissionner — à ne pas confondre avec le harnais lui-même.

14Annexe A — Cycle de vie d'un artefact

Statuts

Règles

• Seul un artefact Validé peut servir de dépendance amont pour la génération d'un artefact aval.
• Toute modification d'un artefact validé le repasse en Brouillon et déclenche l'analyse d'impact sur ses avals.
• La transition En revue → Validé exige une action humaine explicite ; elle est journalisée (qui, quand, commentaire).
• Le statut Archivé est irréversible ; l'archivage inclut les métadonnées et le contexte de décision.

15Annexe B — Registre : exigences et sauvegarde

Exigences fonctionnelles

• Versionnage : chaque artefact conserve l'historique complet de ses versions ; une version est immuable.
• Métadonnées obligatoires : type, version, statut, auteur (agent ou humain), horodatage, liens de dépendance, référentiel appliqué.
• Machine à états : implémente les statuts et transitions de l'annexe A.
• Propagation : l'enregistrement d'une modification amont doit générer la liste des artefacts avals impactés (analyse d'impact) et leur alerte.
• Recherche et consultation : lecture possible par type, statut, auteur, dépendance, mot-clé — y compris en mode lecture seule après clôture.

Exigences non fonctionnelles

• Persistance : survit aux arrêts et redémarrages du harnais ; sauvegarde automatique (fréquence configurable, défaut : quotidienne) avec conservation d'historique de sauvegardes.
• Intégrité : détection de corruption ou de modification illégitime (empreintes/checksums par version, journal d'audit append-only).
• Contrôle d'accès : lecture étendue aux parties prenantes ; écriture réservée aux agents et à l'orchestrateur ; transition de statut réservée aux humains autorisés (rôles par point de contrôle).
• Confidentialité : les artefacts sensibles (données personnelles, secrets) sont chiffrés au repos ; le principe du moindre privilège s'applique aussi à la lecture.
• Exportabilité : export complet du registre à tout moment (format ouvert), exigé par le décommissionnement et la continuité d'activité.