Manifeste
Le futur du codage
est déjà là
Ce n’est pas un rêve. C’est une décision.
01 — Le constat
Le codage assisté par l’IA n’est plus un gadget de démo ni une promesse vague. Des compagnies font exactement ça — à l’échelle industrielle, sur des bases de code legacy en production — maintenant.
Stripe l’a documenté publiquement avec ses agents de codage bout-en-bout (Minions). Des équipes de développeurs expérimentés en discutent ouvertement. Ce n’est plus de la science-fiction. C’est un choix audacieux. Et c’est disponible maintenant.
02 — Le changement de paradigme
L’ancien modèle : le développeur est la machine à coder.
Le nouveau modèle : le développeur est le cerveau qui dirige la machine.
| Avant | Après |
|---|---|
| Je code | Je définis ce qui doit être codé |
| Je débogue | Je valide que les critères sont atteints |
| Je cherche comment faire | Je décide quoi faire et pourquoi |
| Je suis dans l’implémentation | Je suis l’architecte, l’analyste, le product owner |
L’humain devient 100 % focalisé sur :
- les requis précis et sans ambiguïté ;
- les contraintes techniques et fonctionnelles ;
- les objectifs et les non-objectifs ;
- la révision critique des plans et du code produit ;
- les critères de succès détaillés avant même qu’une ligne soit écrite.
03 — Comment ça fonctionne concrètement
Docker comme clean-room garantie
Pas de « fonctionne sur ma machine ». Le build est embarqué dans Docker — c’est un build optimisé spécifiquement pour Docker qui livre un environnement propre à chaque fois. Un docker-compose up = environnement complet, build propre, tests qui roulent.
Un sandboxing complet pour que l’agent puisse agir avec une pleine autonomie opérationnelle, tester, casser, recommencer — sans risque sur l’environnement réel.
La pyramide de tests comme filet de sécurité
Chaque zone de code qu’on commence à toucher → on écrit d’abord des tests de caractérisation du comportement existant. L’agent ne code pas dans le vide ; il code sous surveillance.
Une base documentaire vivante
L’agent a besoin de contexte. Ce contexte vit dans le dépôt :
- AGENTS.md — règles fortes, patterns documentés, pièges connus ;
- PAYMENT_PROCESS.md — plan de travail structuré et traçable ;
- directives spécifiques par module ou domaine.
Ce n’est pas de la documentation pour la documentation. C’est le contrat de travail entre l’humain et l’agent. Plus ce contrat est précis, plus l’agent est efficace.
04 — Le principe structurant : des frontières
Un agent de codage est aussi bon que le contexte qu’on lui fournit. Sa fenêtre de contexte a des limites réelles — cognitives et physiques. C’est ici que l’architecte-humain joue un rôle irremplaçable.
Le piège : le codage horizontal
Changer la stratégie de sérialisation dans 12 modules, refactorer un pattern transversal sur toute la codebase — ce sont des chantiers horizontaux. Ils diluent le contexte de l’agent jusqu’à la rupture. Il perd le fil, produit des incohérences, rate les effets de bord.
L’alternative : des verticales délimitées
Travailler sur une verticale bien définie — le flux de paiement de l’API jusqu’à la DB, le module d’authentification de la validation au token — permet à l’agent de tenir l’ensemble du problème en tête. Il opère dans un monde fermé où toutes les pièces sont visibles, les dépendances connues, les effets de bord contenibles.
La frontière n’est pas une contrainte — c’est une condition de succès. Un agent souverain dans un monde bien délimité produit un code cohérent et testé. Un agent noyé dans un chantier transversal produit du bruit.
Ce découpage en verticales intégrées n’est pas nouveau — c’est ce que le DDD (Domain-Driven Design) appelle les bounded contexts. Ce qui est nouveau, c’est que ces frontières deviennent l’unité de travail de l’agent.
Définir ces frontières est le travail de l’architecte. C’est difficile, intentionnel, et ça demande une connaissance profonde du domaine. C’est précisément pourquoi c’est un travail humain non délégable.
05 — Ce que ça change : le nouveau cycle
L’IDE devient un outil de code review et de validation de qualité — naviguer rapidement, critiquer, questionner, élaborer des plans d’amélioration ciblés. Pas un outil de production.
- Définir l’intention claire
- Documenter les contraintes et critères de succès
- Déléguer à l’agent + sandboxing Docker
- Réviser le code produit (intent vs réalité)
- Itérer si nécessaire
- Valider : tests fonctionnels + stack complet
06 — Pourquoi maintenant ?
Parce que la fenêtre d’avantage compétitif est ouverte maintenant. Les compagnies qui adoptent ce paradigme accumulent de la vélocité. Celles qui attendent accumulent du retard.
Nous avons déjà les ingrédients :
- une base de code qu’on connaît ;
- une infrastructure Docker existante ;
- des outils de tests en place ;
- des agents de codage capables de travailler sur du code legacy.
Ce qui manque, c’est la décision et la discipline d’opérer différemment.
07 — Le futur qu’on peut bâtir
Chaque membre de l’équipe devient un mini product owner de sa zone de responsabilité :
- analyste principal de son domaine ;
- architecte des décisions de design ;
- directeur de projet pour les agents de codage ;
- gardien de la qualité via la révision et les tests.
Ce n’est pas moins de travail. C’est un travail différent — plus stratégique, plus impactant, plus proche de la valeur réelle qu’on livre.
La vélocité potentielle est sans précédent. Le coût humain par feature livré s’effondre. La qualité monte parce que les cerveaux humains sont focalisés là où ils apportent le plus de valeur.
08 — Par où commencer
C’est exigeant. Le démarrage demande un investissement réel.
Mais la trajectoire est claire : chaque effort investi dans ce paradigme se capitalise — les docs, les tests, les règles s’accumulent et rendent les itérations suivantes exponentiellement plus rapides.
Se mettre en mouvement maintenant, c’est choisir la vélocité durable.
English : Same manifesto in English
Voir aussi : Parallèle IA générative et No-Code / Low-Code