Contexte et principes
L’article explique que les agents de codage assistés par IA fonctionnent de façon optimale lorsque toutes les informations nécessaires résident dans le même dépôt Git. Traditionnellement, les équipes utilisent des outils externes comme Jira ou Redmine pour suivre les tickets, ce qui crée une fracture entre le code et les exigences. En stockant chaque tâche sous forme de fichier Markdown dans le dépôt, le même système de versionnage gère à la fois le code, la documentation et les exigences, offrant ainsi une source de vérité unique.
Workflow détaillé
Le processus proposé s’articule autour de cinq étapes précises : (1) description de la tâche sous forme de texte concis, (2) analyse des exigences par l’agent IA qui parcourt le code et la documentation, (3) élaboration d’un plan d’implémentation ajouté au même fichier, (4) révision et approbation humaine du plan, et (5) exécution du changement avec mise à jour du code, de la documentation et ajout d’un rapport d’implémentation. Chaque étape laisse une trace dans le même fichier Markdown, ce qui simplifie la traçabilité et la revue.
Architecture des dépôts et contrôle d’accès
L’auteur utilise trois dépôts Git distincts : un dépôt « code », un dépôt « documentation » et un dépôt « tasks ». Cette séparation répond à des exigences d’accès différentes ; la documentation peut être publique, tandis que les tickets peuvent contenir des informations sensibles (correctifs de sécurité, plans de produit). Le dépôt de tâches est cloné localement dans le répertoire du code, puis exclu du suivi principal via le fichier
.gitignore
/docs/
/tasks/. Chaque dépôt conserve son historique propre, tout en restant synchronisable indépendamment. L’interface web de Typemill se connecte aux dépôts pour offrir une édition via le navigateur sans remplacer Git comme système de versionnage.Analyse des impacts et limites
Cette approche renforce la cohérence entre exigences et implémentation : l’agent IA accède directement aux tickets, ce qui réduit le besoin de requêtes externes. Le suivi versionné facilite la génération de changelogs et de notes de version, car les dossiers de release contiennent les fichiers de tâches terminées. Cependant, le modèle repose entièrement sur Git ; les équipes doivent accepter la gestion de fichiers Markdown comme format de ticket, ce qui peut limiter l’usage de fonctionnalités avancées des systèmes de suivi classiques (workflow automatisé, champs personnalisés, notifications). De plus, la nécessité d’une étape de validation humaine reste indispensable pour éviter les modifications non désirées, surtout lorsqu’il s’agit de correctifs de sécurité. Enfin, la mise en place de dépôts séparés augmente la complexité de la configuration initiale et requiert une discipline stricte dans la gestion des .gitignore et des droits d’accès.