Voilà quelques mois que je n'écris plus moi-même la moindre ligne de code. Plus aucun script, plus aucun patch, plus aucune refacto faite à la main.
Ce que je rédige, ce sont des tickets. Des objectifs, des résultats attendus, des critères d'acceptation — exactement comme un Product Owner le ferait dans Jira. Sauf que celui qui prend le ticket n'est pas un humain : c'est une IA. Elle reformule ce qu'elle a compris, ouvre une branche, livre le travail puis me rend son rapport. On itère ensemble jusqu'à ce que la tâche soit réellement terminée.
Et on ne traite pas un ticket à la fois. On en fait avancer cinq, dix, quinze, parfois vingt en parallèle.
Qu'est-ce qu'un Agentic Development Environment ?
Un Agentic Development Environment (ADE) n'est pas un IDE sur lequel on aurait greffé une IA. C'est un environnement pensé dès le départ pour que des agents IA réalisent le travail à votre place, avec vous dans le rôle d'arbitre plutôt que d'exécutant.
Dans un IDE classique, vous êtes au centre : vous éditez, vous testez, vous commitez, et l'IA se contente de suggérer. Dans un ADE, vous formulez l'intention — l'IA s'occupe du reste et vous validez le résultat. Le glissement d'unité de travail est total : on ne raisonne plus en fichier, mais en ticket.
Pourquoi un kanban et pas un chat ?
La plupart des produits IA pour développeurs prennent la forme d'un chat. C'est agréable en usage solo, mais ça s'écroule dès qu'on veut mener plusieurs tâches de front :
- Un chat est linéaire ; un projet est arborescent.
- Un chat oublie le contexte d'une session à l'autre ; un ticket le transporte avec lui.
- Un chat ne sait pas exprimer « cette tâche est bloquée par celle-là » ; un kanban, si.
- Un chat ne se relit pas ; un ticket fait office de spec, de log d'exécution et de mémoire long terme du projet.
Le kanban est le format natif de cette façon de travailler. Une carte = une intention. Un statut = un état du monde (À faire, En cours, En attente de validation, Échec, Fait). Une colonne « En cours » qui empile quinze cartes n'est plus un mode dégradé — c'est le mode nominal.
Comment 15 tickets peuvent avancer en parallèle
Ce qui rend la chose techniquement possible, ce sont les worktrees Git. Chaque ticket s'exécute dans son propre worktree — une copie isolée du dépôt, sur sa propre branche, sans toucher aux autres. Quinze tickets, quinze worktrees, quinze branches. Zéro conflit d'état pendant l'exécution.
En fin de course, chaque ticket est rebasé sur la branche de base avant d'être réintégré. Si la base a bougé pendant qu'un agent travaillait, on rejoue les tests sur la version rebasée — c'est le seul moyen d'éviter que deux tickets verts en isolation finissent par casser l'intégration.
Les hooks Git comme garde-fou
Quand une IA produit du code en continu, il vous faut des filets de sécurité automatisés. Les hooks Git deviennent alors centraux : lint, formatage, typecheck, tests unitaires — tout se joue au pre-commit. Si un hook échoue, le commit échoue, et l'agent diagnostique, corrige, retente.
Aucun --no-verify. Jamais. Le hook n'est pas une suggestion : c'est le contrat passé avec la branche.
Et quand quelque chose casse malgré tout ?
Aucun système n'est infaillible. Quand un agent se trompe, qu'un test passe en local mais tombe en CI, ou qu'un déploiement part de travers, on ne sort pas le clavier pour réparer à la main. On crée un ticket — un ticket qui charge un autre agent de remonter à la cause racine dans la pipeline. L'ADE devient ainsi son propre garde-fou : il sait s'auto-diagnostiquer.
Ça semble contre-intuitif, mais c'est précisément ce qui rend l'orchestration tenable dans la durée. Sans cette boucle, on retombe dans le vieux piège du « j'allais juste corriger ça vite fait à la main » — et le bénéfice de l'orchestration s'évapore en un quart d'heure.
Deux mois en production
Ce système tourne depuis deux mois. Deux mois que je développe Singularity avec Singularity. Le produit s'utilise lui-même au quotidien, en prod, sur un vrai projet avec de vrais utilisateurs.
Le gain de vitesse, mesuré sans tricher, tourne autour de 50× sur les tâches que je faisais auparavant à la main. Et je sais que je suis encore loin du plafond. Ma limite n'est plus ma vitesse de frappe, ni ma capacité à garder cinq sujets en tête simultanément — c'est la qualité de mes specs. C'est la seule chose qui demeure 100 % humaine.
FAQ
Un ADE remplace-t-il complètement un IDE ?
Non. Singularity expose un terminal et un éditeur de code natifs — vous pouvez intervenir à la main à tout moment. L'idée n'est pas d'interdire le code humain, c'est de le rendre optionnel. La plupart du temps, on n'en a plus besoin.
Comment l'IA comprend-elle un ticket mal écrit ?
Mal. C'est précisément pour ça que la qualité du ticket compte. Un agent IA bien orchestré reformule ce qu'il a compris avant de partir coder, et vous arbitrez le contrat. Si la reformulation est à côté, vous corrigez avant de lancer l'exécution.
Que se passe-t-il quand deux tickets touchent les mêmes fichiers ?
Chaque ticket travaille dans son propre worktree, donc l'exécution n'a pas de conflit. À la réintégration, le second ticket rebase sur le résultat du premier. S'il y a conflit, l'IA propose une résolution motivée, vous arbitrez.
Quelle confiance accorder au code généré ?
Celle que vous accordez à vos hooks et à vos tests. Le code n'est pas cru sur parole parce qu'une IA l'a écrit — il passe les mêmes garde-fous que tout autre code. Si la suite de tests est faible, l'orchestration mettra ça à nu très vite.
Est-ce que ça marche sur n'importe quel projet ?
Plus le projet est testé, plus l'orchestration est efficace. Sur un projet sans tests, l'IA livrera vite mais vous arbitrerez plus. Sur un projet bien outillé (hooks, CI, tests), le ratio human/IA bascule très vite en faveur de la vitesse.
Singularity, le produit maison de Meteor Factory
Singularity est l'environnement de développement agentique conçu et utilisé au quotidien par Meteor Factory. Découvrez Singularity et testez-le gratuitement sur singularity.meteorfactory.dev.