Depuis quarante ans, l'outil du développeur s'appelle l'IDE : un Integrated Development Environment. Un éditeur de texte augmenté — complétion, débogueur, refactoring, intégration Git. L'hypothèse fondatrice n'a jamais bougé : c'est vous qui tapez le code, et l'outil rend cette frappe plus confortable.
Une nouvelle catégorie est en train d'émerger, et elle casse cette hypothèse : l'ADE, pour Agentic Development Environment. Son pari : faire du workflow, et non de l'éditeur, le centre du produit. L'éditeur devient un panneau parmi d'autres — une trappe de secours pour éditer à la main, plus le lieu où l'on vit.
Le vrai changement : l'unité de travail
La différence entre un IDE et un ADE ne se joue pas sur les fonctionnalités. Elle se joue sur une seule question : quelle est l'unité de travail ?
Dans un IDE, l'unité de travail est le fichier — voire la sélection que vous êtes en train d'éditer. Vous ouvrez un fichier, vous tapez, vous sauvegardez, vous commitez. Le travail est « fini » quand le fichier est sauvegardé.
Dans un ADE, l'unité de travail est la tâche, livrée sous forme de branche et de pull request. Vous décrivez une intention ; un agent l'exécute ; le travail est « fini » quand la PR est relue et fusionnée. Vous n'êtes plus l'auteur qui tape, vous êtes le relecteur qui arbitre.
IDE classique vs ADE : le tableau
On peut résumer le basculement en six questions. Voici comment chaque approche y répond :
| Question | IDE classique | ADE |
|---|---|---|
| Unité de travail | Une édition, une sélection dans un fichier | Une tâche livrée en branche + pull request |
| Votre rôle | Auteur qui tape activement | Relecteur qui supervise plusieurs agents |
| Planification | Implicite, dans votre tête | Spécification écrite, validée avant de coder |
| Concurrence | Un développeur, un contexte à la fois | Plusieurs agents sur des branches Git séparées |
| Centre de l'espace de travail | Le fichier ouvert dans l'éditeur | Le kanban et le workflow |
| Travail terminé | Un fichier sauvegardé | Une pull request relue et fusionnée |
Les deux garanties dures d'un ADE
Un chat IA collé à un éditeur n'est pas un ADE. Ce qui fait qu'un environnement mérite le nom, ce sont deux garanties structurelles, pas deux features cosmétiques :
- L'isolation Git. Chaque agent travaille sur sa propre branche, dans son propre espace. Sans ça, dès que deux agents tournent en même temps, plus personne ne sait « quelles modifications sont dans l'arbre de travail, quelle tâche a touché quel fichier ». L'isolation n'est pas un confort, c'est ce qui rend le parallélisme possible.
- Le gating par la spec. On ne code pas tant que le plan n'est pas approuvé. L'agent reformule ce qu'il a compris, vous validez le contrat, ensuite il ouvre une branche. C'est ce qui empêche l'IA de partir vite dans la mauvaise direction.
Ces deux garanties expliquent pourquoi l'ADE n'est pas « un IDE avec un chat ». Un chat est linéaire et sans état ; un projet est arborescent et concurrent. Il fallait une nouvelle forme.
Pourquoi maintenant ?
Parce que le goulot d'étranglement a changé de place. Il y a cinq ans, la limite d'un développeur était sa vitesse de frappe et sa capacité à naviguer dans un gros codebase — d'où un IDE optimisé pour taper et naviguer vite. Aujourd'hui, un agent IA écrit le code plus vite que vous ne le relisez. La limite n'est plus la frappe : c'est votre capacité à décrire clairement et à arbitrer beaucoup de travail en parallèle. L'outil devait suivre ce déplacement.
Comment Singularity se différencie
Singularity est l'ADE qu'on construit chez Meteor Factory. Il prend les deux garanties ci-dessus et va au bout de la logique. Voici ce qui le distingue concrètement.
1. Un kanban, pas un chat
La surface principale de Singularity n'est ni un éditeur, ni une fenêtre de chat : c'est un kanban. Une carte = une intention. Une colonne = un état du monde (À faire, En cours, En attente de validation, Échec, Fait). Une colonne « En cours » qui contient quinze cartes n'est pas un mode dégradé — c'est le mode normal. Le ticket porte son propre contexte, sa spec, son log d'exécution et sa mémoire long terme. Un chat oublie d'une session à l'autre ; un ticket, non.
2. Un worktree Git par ticket
Chaque ticket s'exécute dans son propre worktree Git : une copie isolée du dépôt, sur sa propre branche. Quinze tickets, quinze worktrees, quinze branches, zéro conflit d'état pendant l'exécution. À la fin, chaque ticket est rebasé sur la branche de base avant réintégration — et 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.
3. Des hooks de test non contournables
Quand l'IA produit du code à la chaîne, les garde-fous doivent être automatiques. Chez Singularity, les hooks Git — lint, format, typecheck, tests — tournent au pre-commit et ne sont jamais contournables. Pas de --no-verify, jamais. Si un hook échoue, le commit échoue, l'agent diagnostique, corrige, retente. Le hook n'est pas une suggestion, c'est le contrat avec la branche.
4. Des dépendances entre tickets
Un projet réel n'est pas une liste plate de tâches indépendantes. Singularity sait exprimer qu'« un ticket est bloqué par un autre », qu'un parent se décompose en enfants, et orchestre l'ordre d'exécution en conséquence. C'est exactement ce qu'un chat linéaire ne peut pas faire.
5. Natif et privacy-first
Singularity est un client natif macOS, Windows et Linux, pas un onglet de navigateur. Le code, les tickets et l'orchestration vivent en local sur votre machine. Vous gardez un éditeur et un terminal natifs comme trappe de secours — l'intervention humaine à la main reste possible à tout instant, elle devient simplement optionnelle.
6. Il se développe lui-même
La meilleure preuve qu'un ADE tient debout, c'est qu'il serve à se construire. Singularity est développé avec Singularity, en production, tous les jours, 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 faites avant à la main. Et la limite restante n'est plus technique : c'est la qualité des specs. La seule chose qui reste 100 % humaine.
FAQ
Quelle est la différence entre un IDE et un ADE ?
Un IDE met l'éditeur de fichiers au centre : vous êtes l'auteur qui tape le code, l'IA suggère. Un ADE met le workflow au centre : vous décrivez une tâche, des agents IA la livrent sous forme de branches et de pull requests, et vous devenez le relecteur qui arbitre. L'unité de travail passe du fichier au ticket.
Un ADE remplace-t-il un IDE ?
Non, il l'absorbe. Un ADE comme Singularity embarque un éditeur et un terminal natifs comme trappe de secours, mais ce ne sont plus les surfaces principales. La plupart du temps vous vivez dans le kanban, pas dans l'éditeur.
Comment plusieurs agents peuvent-ils coder en parallèle sans se marcher dessus ?
Chaque tâche s'exécute dans son propre worktree Git — une copie isolée du dépôt sur sa propre branche. Dix tâches, dix worktrees, dix branches. Aucun conflit d'état pendant l'exécution ; la réintégration se fait par rebase, une tâche après l'autre.
En quoi Singularity se différencie des autres ADE ?
Singularity est un ADE basé sur le kanban, natif macOS/Windows/Linux, avec des worktrees Git par ticket, des hooks de test non contournables, une orchestration multi-agents avec dépendances entre tickets, et un fonctionnement privacy-first en local. Il se développe lui-même : Singularity est construit avec Singularity.
Pour aller plus loin
Si vous voulez le retour d'expérience concret sur cette manière de travailler, lisez « Un ADE basé sur le kanban : comment j'écris des tickets pendant que l'IA code ». Pour la philosophie produit qui sous-tend tout ça, il y a le manifesto. Et pour rejoindre la liste d'attente, l'inscription est ici.