Ça fait quelques mois que je ne code plus moi-même. Plus une ligne. Plus de script, plus de patch, plus de refacto à la main.
À la place, j'écris des tickets. Des objectifs, des résultats attendus, des critères d'acceptation. Comme le ferait un Product Owner dans Jira, sauf que ce n'est pas un humain qui prend le ticket — c'est une IA. Elle reformule ce qu'elle a compris, ouvre une branche, livre le travail, me fait son rapport. On itère jusqu'à ce que la tâche soit correctement terminée.
Et on n'avance pas sur un ticket à la fois. On avance sur 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 avec une IA collée dessus. C'est un environnement conçu pour que des agents IA fassent le travail à votre place, avec vous comme arbitre et non plus comme exécutant.
Dans un IDE classique, vous êtes au centre : vous éditez, vous testez, vous commitez. L'IA suggère. Dans un ADE, vous écrivez l'intention — l'IA fait le reste, et vous validez le résultat. Le changement d'unité de travail est radical : ce n'est plus le fichier, c'est le ticket.
Pourquoi un kanban et pas un chat ?
La plupart des produits IA pour développeurs sont des chats. C'est confortable à l'usage individuel, mais ça s'effondre dès qu'on essaie de mener plusieurs tâches en parallèle :
- Un chat est linéaire ; un projet est arborescent.
- Un chat oublie le contexte d'une session à l'autre ; un ticket le porte avec lui.
- Un chat ne sait pas dire « cette tâche est bloquée par celle-là » ; un kanban, si.
- Un chat ne se relit pas ; un ticket sert de spec, de log d'exécution et de mémoire long terme du projet.
Le kanban est le format natif de cette manière 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 contient quinze cartes, ce n'est plus un mode dégradé — c'est le mode normal.
Comment 15 tickets peuvent avancer en parallèle
La pièce qui rend ça possible techniquement, 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 interférer avec les autres. Quinze tickets, quinze worktrees, quinze branches. Aucun conflit d'état pendant l'exécution.
À la fin, chaque ticket est rebased 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 la seule façon d'éviter que deux tickets verts en isolation produisent une intégration cassée.
Les hooks Git comme garde-fou
Quand une IA produit du code à la chaîne, vous avez besoin de filets de sécurité automatisés. Les hooks Git deviennent centraux : lint, formatage, typecheck, tests unitaires — tout passe au pre-commit. Si un hook échoue, le commit échoue, l'agent diagnostique, corrige, retente.
Aucun --no-verify. Jamais. Le hook n'est pas une suggestion, c'est le contrat 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 échoue en CI, ou qu'un déploiement déraille, on ne corrige pas à la main. On crée un ticket. Un ticket qui demande à un autre agent d'aller chercher la cause racine dans la pipeline. L'ADE devient son propre garde-fou : il sait s'auto-diagnostiquer.
Ça paraît contre-intuitif, mais c'est ce qui rend l'orchestration soutenable. Sans cette boucle, on retombe dans le piège classique du « j'allais juste fixer ça vite à la main » — et on perd le bénéfice de l'orchestration en quinze minutes.
Deux mois en production
Ça fait deux mois que ce système tourne. 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é honnêtement, est de l'ordre de 50× sur les tâches que je faisais avant à la main. Et j'ai conscience d'être encore loin du plafond. La limite n'est plus ma vitesse de frappe, ni ma capacité à maintenir le contexte de cinq sujets en parallèle dans ma tête — c'est la qualité de mes specs. C'est la seule chose qui reste 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 sort bientôt
Singularity est l'application qu'on développe pour faire tourner cet ADE au quotidien. Client natif macOS, Windows et Linux. La release publique arrive bientôt.
Pour comprendre la philosophie produit qui sous-tend tout ça, lisez le manifesto. Pour rejoindre la liste d'attente, l'inscription est ici.