Les Artefacts
Temps de lecture estimé : 15 minutes
Le principe fondamental
Section intitulée « Le principe fondamental »Les artefacts sont des outils de réflexion et de communication, pas de la bureaucratie.
Un artefact AIAD n’existe pas pour remplir un processus ou satisfaire un audit. Il existe parce qu’il remplit une fonction précise : aligner l’équipe, guider les agents, ou vérifier la qualité des résultats. Si un artefact ne remplit aucune de ces fonctions, il n’a pas sa place dans le framework.
Cette distinction est cruciale dans un contexte IA. Les agents ont besoin de contexte structuré pour produire des résultats de qualité. Un artefact bien rédigé est littéralement l’input qui détermine la qualité de l’output. Investir dans la qualité des artefacts est l’un des leviers les plus puissants pour améliorer les résultats des agents.
Les quatre critères d’un bon artefact
Section intitulée « Les quatre critères d’un bon artefact »Chaque artefact AIAD doit satisfaire quatre critères :
1. Actionnable
Section intitulée « 1. Actionnable »L’artefact doit permettre à son lecteur (humain ou agent) de passer à l’action immédiatement. Un PRD qui décrit une vision sans critères d’acceptation n’est pas actionnable. Un SPECS qui liste des exigences sans exemples concrets n’est pas actionnable.
Test : après avoir lu l’artefact, le lecteur sait-il exactement quoi faire ?
2. Vivant
Section intitulée « 2. Vivant »Un artefact n’est jamais « terminé ». Il évolue avec le projet, les apprentissages de l’équipe et les retours utilisateurs. Un PRD figé au jour 1 est un artefact mort. Un AGENT-GUIDE qui n’intègre pas les leçons apprises des dernières générations est un artefact mort.
Test : l’artefact a-t-il été mis à jour dans les deux dernières semaines ?
3. Minimal
Section intitulée « 3. Minimal »L’artefact ne contient que l’information nécessaire à sa fonction. Pas de sections « au cas où », pas de descriptions redondantes, pas de formalisme excessif. Chaque ligne doit justifier sa présence.
Test : peut-on supprimer un paragraphe sans perdre d’information essentielle ?
4. Collaboratif
Section intitulée « 4. Collaboratif »L’artefact appartient à l’équipe, pas à son auteur initial. Tout membre de l’équipe peut (et doit) le challenger, le compléter ou le corriger. La propriété intellectuelle individuelle n’a pas sa place dans les artefacts AIAD.
Test : l’artefact est-il accessible et compréhensible par tous les membres de l’équipe ?
Les quatre artefacts essentiels
Section intitulée « Les quatre artefacts essentiels »Le framework AIAD définit quatre artefacts essentiels. Chacun répond à une question fondamentale et est maintenu par un responsable identifié.
Vue d’ensemble
Section intitulée « Vue d’ensemble »| Artefact | Question centrale | Responsable | Audience principale |
|---|---|---|---|
| PRD | Pourquoi et quoi construire ? | PM | Toute l’équipe |
| ARCHITECTURE | Quels standards techniques ? | Tech Lead | PE, AE, QA |
| AGENT-GUIDE | Quel contexte pour les agents ? | AE + PE | Agents IA |
| SPECS | Comment implémenter précisément ? | PE | Agents IA |
PRD — Product Requirements Document
Section intitulée « PRD — Product Requirements Document »Le PRD est le document fondateur de chaque initiative. Il décrit le problème à résoudre, les utilisateurs concernés, la solution envisagée et les critères de succès mesurables.
Dans un contexte AIAD, le PRD joue un rôle amplifié : il est la source de vérité que toute l’équipe — y compris les agents — utilise pour comprendre le pourquoi derrière chaque fonctionnalité.
Contenu essentiel :
- Contexte et problème à résoudre
- Utilisateurs cibles et leurs besoins
- Solution proposée avec périmètre clair (in scope / out of scope)
- Critères de succès mesurables (métriques d’impact)
- Critères d’acceptation de haut niveau
- Priorités et dépendances
Ce que le PRD n’est pas : le PRD n’est pas une spécification technique détaillée. Il ne décrit pas comment implémenter la solution, mais quoi construire et pourquoi.
En savoir plus : Template PRD
ARCHITECTURE — Document d’architecture
Section intitulée « ARCHITECTURE — Document d’architecture »Le document ARCHITECTURE définit les standards techniques du projet : conventions de code, patterns à suivre, structure du projet, choix technologiques et leurs justifications.
Pour les agents IA, ce document est fondamental : il leur fournit le cadre dans lequel le code généré doit s’inscrire. Sans document d’architecture, chaque génération risque de produire du code techniquement correct mais stylistiquement incohérent avec le reste du projet.
Contenu essentiel :
- Stack technique et justifications
- Structure du projet (arborescence de fichiers)
- Conventions de nommage et de style
- Patterns architecturaux retenus (et ceux explicitement rejetés)
- Stratégie de gestion des erreurs
- Stratégie de tests
- Contraintes de performance et de sécurité
En savoir plus : Template ARCHITECTURE
AGENT-GUIDE — Guide des agents
Section intitulée « AGENT-GUIDE — Guide des agents »L’AGENT-GUIDE est le document qui fournit aux agents IA le contexte spécifique du projet. C’est le pont entre les connaissances générales de l’agent et les particularités de votre codebase, votre domaine métier et vos conventions.
C’est l’artefact avec le meilleur retour sur investissement : une heure passée à rédiger un AGENT-GUIDE précis économise des dizaines d’heures de corrections et d’itérations sur les générations futures.
Contenu essentiel :
- Contexte du projet (domaine métier, objectifs, contraintes)
- Conventions spécifiques au projet
- Bibliothèques et outils à utiliser (et à éviter)
- Exemples de code représentatifs du style attendu
- Patterns récurrents et comment les implémenter
- Erreurs fréquentes des agents et comment les éviter
En savoir plus : Template AGENT-GUIDE
SPECS — Spécifications d’implémentation
Section intitulée « SPECS — Spécifications d’implémentation »Le SPECS est le document le plus granulaire : il décrit précisément ce qu’un agent doit produire pour une fonctionnalité donnée. C’est l’input direct de l’agent pendant la phase d’implémentation.
La qualité du SPECS détermine directement la qualité du code généré. Un SPECS vague produira un code générique. Un SPECS précis, avec des exemples concrets et des critères d’acceptation détaillés, produira un code proche de l’attendu dès la première génération.
Contenu essentiel :
- Référence au PRD parent (contexte et objectif)
- Description fonctionnelle détaillée du comportement attendu
- Critères d’acceptation exhaustifs (cas nominaux et cas limites)
- Exemples concrets d’entrées/sorties
- Contraintes techniques spécifiques
- Maquettes ou wireframes si applicable
- Référence aux sections pertinentes de l’ARCHITECTURE et de l’AGENT-GUIDE
En savoir plus : Template SPECS
Les Definitions of Done
Section intitulée « Les Definitions of Done »En complément des quatre artefacts essentiels, AIAD définit deux documents de référence qui encadrent la notion de « terminé ».
DoOD — Definition of Obvious Done
Section intitulée « DoOD — Definition of Obvious Done »La DoOD liste les critères non négociables qu’un livrable doit satisfaire avant d’être considéré comme terminé. Ce sont des critères objectifs, vérifiables mécaniquement pour la plupart.
Exemples de critères DoOD :
- Le code compile sans erreur
- Tous les tests unitaires passent
- Le linter ne rapporte aucune erreur
- Les critères d’acceptation du SPECS sont satisfaits
- La documentation API est à jour
La DoOD est le filet de sécurité minimal. Si un livrable ne satisfait pas la DoOD, il n’est tout simplement pas terminé — aucune discussion possible.
En savoir plus : Template DoOD
DoOuD — Definition of Outstanding Done
Section intitulée « DoOuD — Definition of Outstanding Done »La DoOuD définit les critères d’excellence qu’un livrable peut atteindre au-delà de la DoOD. Ce sont des critères aspirationnels qui tirent l’équipe vers le haut.
Exemples de critères DoOuD :
- La couverture de tests dépasse 80 %
- Les temps de réponse sont inférieurs à 200ms
- L’accessibilité WCAG AA est respectée
- Le code est documenté avec des exemples d’utilisation
- Les edge cases sont gérés de manière élégante
La DoOuD n’est pas obligatoire pour chaque livrable, mais elle guide l’amélioration continue de l’équipe.
En savoir plus : Template DoOuD
Erreurs fréquentes
Section intitulée « Erreurs fréquentes »« On n’a pas le temps de rédiger des specs »
Section intitulée « « On n’a pas le temps de rédiger des specs » »C’est le paradoxe le plus courant. Les équipes qui disent ne pas avoir le temps de rédiger des spécifications sont précisément celles qui passent le plus de temps à corriger les résultats des agents. 30 minutes de spécification économisent 2 heures de correction.
« L’AGENT-GUIDE fait 100 pages »
Section intitulée « « L’AGENT-GUIDE fait 100 pages » »Un AGENT-GUIDE trop long est aussi inutile qu’un AGENT-GUIDE inexistant. Les agents ont des limites de contexte, et un document trop volumineux noie l’information pertinente dans le bruit. Visez un AGENT-GUIDE de 2 à 5 pages maximum, dense et ciblé.
« Le PRD est figé depuis le début du projet »
Section intitulée « « Le PRD est figé depuis le début du projet » »Un PRD qui ne change jamais est un signe que l’équipe n’apprend pas. Les retours utilisateurs, les découvertes techniques et l’évolution du marché doivent se refléter dans le PRD. Mettez en place une revue régulière (hebdomadaire ou bi-hebdomadaire) du PRD.
« Chaque artefact est rédigé par une seule personne »
Section intitulée « « Chaque artefact est rédigé par une seule personne » »Les artefacts sont des outils collaboratifs. Le PM rédige le PRD, mais le PE et le TL doivent le challenger. Le PE rédige les SPECS, mais le QA et le PM doivent les valider. La co-construction améliore la qualité et l’adhésion.
Le cycle de vie des artefacts
Section intitulée « Le cycle de vie des artefacts »Les artefacts ne sont pas créés une fois pour toutes. Ils suivent un cycle de vie naturel :
- Création — rédaction initiale par le responsable
- Revue — validation collaborative par l’équipe
- Utilisation — consommation par les humains et les agents
- Mise à jour — évolution en fonction des apprentissages
- Archivage — quand l’artefact n’est plus pertinent
La fréquence de mise à jour varie selon l’artefact :
- PRD : mis à jour à chaque changement de direction ou apprentissage significatif
- ARCHITECTURE : mis à jour lors de changements structurels
- AGENT-GUIDE : mis à jour en continu à chaque leçon apprise
- SPECS : rédigé pour chaque fonctionnalité, rarement mis à jour après implémentation
Section précédente : Écosystème
Section suivante : Boucles Itératives