Présentation du concept ADRs4AI

ADRs4AI propose de consigner chaque décision collaborative entre un humain et une intelligence artificielle sous forme d’Architecture Decision Record (ADR). Le texte source montre que chaque question est préfixée ### QST, ce qui rend la recherche instantanée via grep -rn '^### QST' docs/adr/. Le processus repose sur un seul jugement humain : accepter, modifier ou rejeter la recommandation générée par l’IA, tout en conservant le raisonnement complet.

Architecture temporelle et modèle bitemporal

Le débat central porte sur la préservation du « what was true » à une date donnée. Trois options sont exposées : A — mutable present truth, B — append‑only assertions et C — bitemporal hybrid. La recommandation, issue de GPT 5.6 Sol, privilégie l’option C. Ce modèle introduit deux axes temporels : le valid‑time (période de validité déclarée) et le observed‑time (moment où l’information a été observée). Les supersession edges relient les versions corrigées aux versions antérieures, garantissant que chaque correction reste traçable sans altérer les enregistrements originaux. Cette double temporalité répond à la critique selon laquelle l’historique Git ne capture que les changements de bits, pas les moments d’effet ou d’annonce.

Intégration avec Git et implications pratiques

Le workflow démarre par la création d’un dépôt à partir d’un modèle : 

gh repo create my-project --private --clone \
  --template ADRs4AI/human-ai-collaboration-template-A
cd my-project
Ensuite, le premier ADR est enregistré avec git add -A && git commit -m "chore: the record begins before the building does". L’IA (Claude, ou tout autre agent) est invoquée, lit le mandat et produit les options, la recommandation, le niveau de confiance et le critère de falsification. Chaque itération ajoute un nouveau fichier ADR, préservant ainsi le raisonnement complet. Git agit comme couche d’audit supplémentaire, tandis que le modèle bitemporal gère les dimensions temporelles de la vérité déclarée.

Limites et perspectives

Le texte indique que le modèle pourrait devoir s’étendre si des temps supplémentaires (par ex. disponibilité produit) sont requis, ce qui montre une reconnaissance explicite des limites du schéma actuel. La dépendance à Git implique que les conflits de fusion doivent être résolus manuellement, ce qui peut compliquer la maintenance dans des équipes nombreuses. De plus, l’absence de métadonnées automatiques pour le valid‑time nécessite que les contributeurs renseignent ces champs de façon cohérente. Malgré ces contraintes, le système offre une traçabilité fine et un moyen de réutiliser le raisonnement, ce qui réduit la perte cognitive lors du passage d’un projet à un autre.