Beaucoup de jeunes pousses offrent des agents d’intelligence artificielle aux entreprises. Elles livrent la solution, et souvent elles la livrent vite.
Mais est-ce que c’est dans une bonne structure ? Est-ce que c’est soutenable ?
Je comprends l’urgence. Les entrepreneurs et les chefs d’organisation veulent profiter de l’IA, en tirer un avantage, et ça évolue tellement vite qu’on sent qu’il faut y aller maintenant.
Il n’y a quand même rien de mieux que quelque chose de bien structuré, dans une bonne architecture. Ça peut évoluer, ça continue de progresser, ça continue de t’aider. Parce que ton organisation, elle, elle dure.
Ce n’est pas juste les fournisseurs qui vont vite
On le fait nous-mêmes aussi.
Un dirigeant s’est lancé seul. Développement assisté par IA, sans structure, très vite. En quelques jours, il avait sorti quelque chose.
Et ça fonctionnait. En partie.
C’est là que le piège se referme, et il ne ressemble pas du tout à un échec.
Un système qui plante, on le voit. Il y a un message d’erreur, une page blanche, un appel du client. On l’arrête, on recommence, on a perdu quelques jours. C’est désagréable et c’est sans gravité.
Un système qui fonctionne à moitié, on l’utilise. C’est toute la différence. Il rend un service réel, donc on s’en sert. On construit dessus. L’équipe s’y habitue, des données s’y accumulent, des processus commencent à en dépendre. Chaque semaine qui passe augmente le coût de le défaire, sans que personne ne prenne cette décision consciemment.
Puis arrive le jour où il faut que ça tienne pour de vrai. Un client plus gros, un volume plus important, une nouvelle personne dans l’équipe qui doit reprendre le dossier. Et là, il n’y a rien à réparer.
Ce qui a été bâti sans structure ne se maintient pas, ne se transmet pas, et ne se corrige pas par retouches. On ne le répare pas. On le refait.
Ce que j’ai écrit en juin, et le mot qui comptait
En juin, j’ai écrit que le vibe coding bien encadré, mené par du monde d’expérience, devenait une arme de compétitivité. Que le sur-mesure redevenait accessible, et qu’une organisation pouvait enfin se doter d’outils qui reflètent sa façon de travailler au lieu de s’adapter à ceux des autres.
Je le pense encore. Le mot important, c’était encadré.
Cette édition n’est pas une rétractation, c’est la deuxième moitié de la phrase. Les mêmes outils, entre les mêmes mains, sans l’encadrement, donnent exactement ce qu’on vient de voir : quelque chose de rapide, d’impressionnant, et d’insoutenable.
C’est important de le dire clairement, parce que la nuance se perd vite. Quand une pratique devient populaire, on retient la partie qui séduit et on oublie la condition qui la rend viable. Le vibe coding a très bien passé cette étape. L’encadrement, beaucoup moins.
Le problème n’a jamais été la vitesse
Il faut être précis ici, parce que le réflexe naturel serait de conclure « ralentissez ».
Ce n’est pas mon propos, et ce serait une mauvaise réponse. La vitesse est un avantage réel. Une organisation qui met neuf mois à décider pendant qu’une autre livre en trois semaines n’est pas plus prudente, elle est simplement en train de perdre. Refuser d’aller vite en 2026 n’est pas de la sagesse.
Le problème, c’est ce qu’on saute pour aller vite.
Et ce qu’on saute en premier, c’est toujours la même chose : le travail de définition. Comprendre le chemin réel de son opération avant de coder quoi que ce soit. Savoir d’où part une demande, par où elle passe, qui décide, où elle attend.
C’est l’étape qui ne produit rien de visible. À la fin d’une journée de définition, il n’y a pas de démo à montrer, pas d’écran qui s’allume, pas de « regarde ce que ça fait ». Il y a une feuille. C’est exactement pour ça qu’elle saute la première quand l’échéancier serre.
Il y a des affaires sur lesquelles je suis moins sûr. Pas celle-là. On peut coder vite. On ne peut pas définir vite. Comprendre comment une organisation fonctionne vraiment demande d’observer, de poser des questions, de se faire corriger par les gens qui font le travail. Aucun outil n’accélère ça, parce que ce n’est pas un problème technique.
Ce qui restait quand tout a été jeté
Revenons au dirigeant.
Il a fini par engager une firme. Ils ont tout refait, de tout au tout.
Il a perdu de l’argent. Il a perdu du temps. Ça ne se rattrape pas, et je ne vais pas prétendre le contraire pour que l’histoire finisse mieux qu’elle n’a fini.
Mais il restait une chose.
Son processus était bien défini. Il savait comment son organisation fonctionnait vraiment, étape par étape, qui décide quoi et où ça attend. Ça, il l’avait fait avant de commencer, et ça n’a pas été jeté avec le reste.
Alors la firme n’est pas repartie de zéro. Elle est repartie de son processus. Elle n’a pas eu à repartir en découverte avant de pouvoir écrire une ligne. Le travail le plus lent était déjà fait, et il était bon.
C’est toute la différence entre recommencer et se reprendre.
Le code, lui, était jetable. Il l’a toujours été, d’ailleurs. Le code que tu écris aujourd’hui sera de toute façon obsolète dans deux ans, quand les outils auront encore changé, et il le sera d’autant plus vite qu’il aura été généré rapidement. Le travail de définition, non. C’est la seule partie qui a survécu à une reprise complète.
Écris le processus, le reste est remplaçable
Si tu pars vite, pars vite. Je ne vais pas te dire d’attendre, l’attente coûte aussi, et elle coûte souvent plus cher que l’erreur.
Mais avant de lancer quoi que ce soit, prends le temps de mettre ton processus au propre. Pas dans un outil, sur du papier. Le chemin réel : d’où part la demande du client, par où elle passe, qui décide, où ça attend, jusqu’à l’argent dans ton compte.
Ça prend une demi-journée. Ça ne demande aucune compétence technique. Et ça ne périme pas.
Ça ne t’empêchera pas de te tromper sur la technologie. Tu vas te tromper, tout le monde se trompe, les outils changent trop vite pour qu’il en soit autrement. Ce n’est pas grave, c’est le coût normal d’une époque qui bouge.
Ça va t’éviter de te tromper deux fois.
Parce que le jour où il faut tout refaire, et ce jour arrive plus souvent qu’on pense, la seule question qui compte est celle-là : est-ce que je repars de zéro, ou est-ce que je repars de quelque chose ?
Fais juste écrire le processus. Le reste est remplaçable.
Pour recevoir l’analyse hebdomadaire sur l’IA et la transformation numérique pour les dirigeants de PME/organisation, inscris-toi à L’Architecte.
