La blague marche parce que ce n’est pas seulement une blague
Appelons cela le Meteor development : la destination est annoncée d’abord, les arrêts changent en cours de route, le budget est supposé se débrouiller tout seul, et engineering doit continuer à poser des rails alors que le train est censé partir “dans une minute”.
Le meme est drôle parce que ce scénario arrive sans arrêt dans de vraies équipes.
Un fondateur promet une feature avant même que les edge cases existent. L’équipe product redessine l’onboarding flow alors que design est déjà passé à autre chose. La direction voit que l’AI a produit l’écran précédent très vite et conclut qu‘“une integration de plus” devrait être facile. L’itinéraire bouge sans cesse. L’échéance, elle, ne bouge pas.
La mauvaise nouvelle, c’est qu’aucun pattern d’architecture ne fera disparaître les attentes irréalistes.
La bonne nouvelle, c’est que ces attentes irréalistes n’ont plus besoin de se transformer automatiquement en engineering paralysis.
La vraie douleur n’a jamais été seulement l’attente
Une mauvaise planification est pénible. Elle brûle du temps, ajoute de la pression et force à renégocier. Mais à elle seule, elle ne détruit pas la delivery.
Ce qui casse vraiment une équipe, c’est quand chaque changement produit tardif devient un risque pour tout le système.
C’est le failure mode classique des codebases AI-generated qui vont vite. La version one sort si rapidement que tout le monde commence à croire que chaque changement futur devrait aller aussi vite. Puis la réalité arrive :
- il faut changer d’auth provider
- analytics doit devenir optional
- un deep link path est faux
- une décision de styling s’est propagée à 40 screens
- une feature “petite” traverse trois modules qui n’auraient jamais dû être couplés
À ce moment-là, l’équipe ne se bat plus seulement contre des attentes irréalistes. Elle est aussi coincée avec une codebase qui ne sait pas absorber le changement localement.
Voilà la double peine. Le problème organisationnel est déjà assez dur. Le problème technique l’aggrave encore.
Meteor development casse d’abord les codebases fragiles
C’est pour cela que ce meme parle autant aux engineers.
Nous avons tous vu le même pattern :
- La route est annoncée avant que la carte soit réelle.
- Le périmètre continue d’enfler alors que l’implementation a déjà commencé.
- La même échéance reste sur la diapositive.
- On demande à engineering de “s’adapter”.
Si le système a des boundaries faibles, “s’adapter” veut en réalité dire :
- faire du reverse engineering sur des abstractions AI-generated que personne n’a réellement conçues
- démêler des modules qui vont piocher dans l’implementation interne des autres
- corriger des regressions dans des zones de l’app que personne ne voulait toucher
- perdre une semaine à préserver la mauvaise implementation
À ce stade, l’équipe ne construit plus le produit. Elle fait de l’archéologie sous pression.
Et c’est précisément cette partie que nous n’avons plus à accepter.
Autotomy change le failure mode
Autotomy ne rend pas les estimations fantaisistes réalistes. Il fait quelque chose de plus utile : il garde le système remplaçable.
L’idée centrale est simple. Quand un module est mauvais, en retard ou ne correspond plus à la route, vous devriez pouvoir le couper, le remplacer et continuer.
Pour cela, il faut quelques éléments non négociables :
- des interfaces autour des services volatils comme auth, analytics, storage et notifications
- un composition root qui décide quelle implementation l’app utilise réellement
- des dependency boundaries qui empêchent une screen d’importer directement des vendor details
- des contract tests et des deterministic checks qui vérifient le comportement au moment du remplacement
- des dependency tiers pour éviter que des tools optional se comportent comme une infrastructure critique au lancement
Avec cela en place, une cible mouvante reste agaçante. Mais elle cesse d’être existentielle.
Un changement de provider devient un replacement derrière une interface. Un détour produit devient une réécriture locale au lieu d’un refactor systémique. Un mauvais module AI-generated devient quelque chose que l’on supprime, pas quelque chose que l’on protège avec précaution.
Quand la route change, le développement peut quand même continuer
C’est le déplacement pratique qui compte vraiment.
Sans Autotomy, Meteor development ressemble à ceci :
“On a encore changé le plan d’onboarding, donc maintenant il faut toucher auth, profile state, analytics, styling et navigation. Donnez-nous une semaine pour comprendre ce qui va casser.”
Avec Autotomy, cela ressemble plutôt à ceci :
“L’attente reste irréaliste, mais le changement est localisé. Il faut renégocier le périmètre ou la date, pas reconstruire toute l’app.”
C’est un bien meilleur mode de défaillance.
Il faudra peut-être encore repousser certaines promesses de livraison. Peut-être faudra-t-il découper le launch, retirer un arrêt de la route ou dire non à une branch line de dernière minute. Mais l’organisation engineering n’a plus besoin de souffrir deux fois. Le problème humain reste humain. Le problème logiciel reste gérable.
La vitesse de l’AI rend cela plus important, pas moins
AI coding est l’une des raisons pour lesquelles le Meteor development apparaît plus souvent aujourd’hui.
Quand Cursor ou Claude Code peuvent générer la first version d’une feature en quelques heures, la direction commence à supposer que chaque itération future devrait se comporter comme la première. On voit la vitesse à la surface et on imagine que le changement est bon marché jusqu’au fond.
Ce n’est pas le cas.
L’AI est excellente pour remplir l’implementation. Elle n’est pas responsable de garder le système structurellement sûr quand la réalité produit change. Si la codebase n’a pas de boundaries, la vitesse de l’AI vous fait seulement arriver plus vite à la fragilité.
C’est pourquoi je reviens toujours au même point : la bonne réponse à l’AI-native development n’est pas plus d’optimisme. C’est plus de remplaçabilité.
Générez vite. Faites respecter les boundaries. Validez de façon déterministe. Supprimez les mauvais modules quand la route change. Gardez le rayon d’impact local.
La partie fantasme reste encore à votre charge
Il n’existe aucun framework qui va entrer dans une réunion de planification pour dire à quelqu’un que sa date de lancement est imaginaire.
Autotomy ne règle ni la priorisation, ni les feuilles de route fantaisistes, ni le fait qu’une partie prenante dessine une nouvelle station sur la carte une fois la construction démarrée.
Cette partie, il faut encore la gérer comme ingénieur et comme adulte.
Mais ce devrait être la seule partie difficile.
Le travail ne devrait pas aussi consister à réanimer une codebase qui s’effondre à chaque fois que le plan bouge.
Si Meteor development reste une sorte de météo organisationnelle permanente, très bien. Qu’il reste un meme sur la gestion des attentes.
Avec Autotomy, il n’a plus besoin d’être aussi un meme sur la souffrance d’ingénierie.