Le shot de dopamine du samedi soir, et le mur du lundi

Un DSI me racontait qu’il code avec Claude Code le week-end. En deux heures, seul dans son salon, il sort une app qui marche. Il m’a parlé du shot de dopamine que ça procure. Grisant. Addictif, presque.

Je le comprends, je vis la même chose. J’adore ces outils, je bosse avec tous les jours.

Mais ce shot masque un truc. « Ça marche sur mon écran le samedi » et « c’est en production le lundi », ce sont deux métiers différents. Et le second, l’outil ne le fait pas à ta place.

« Ça marche » ne veut pas dire « c’est en prod »

Un LLM ne cesse d’halluciner que si on cadre ses appels aux outils. Il tape le CRM, le mail, l’outil interne au bon moment, et il sait quand il ne sait pas. En démo, on lui pose les questions qu’on a préparées et il s’en sort très bien. Le premier utilisateur venu, lui, demandera un délai contractuel ou un remboursement, sur un cas que personne n’avait prévu. Rien n’empêche alors le proto de répondre à côté, sur un ton parfaitement assuré. Et une réponse inventée sur ce ton-là finit par engager l’entreprise.

Un RAG doit tenir sur vos vrais documents. Pas le PDF nickel de la démo, mais le scan de travers, le Word de 2009, le tableau mal exporté, l’image posée au milieu du texte. Le vrai piège n’est même pas le format : il existe souvent trois versions du même document, dont deux périmées, et personne ne sait laquelle fait foi. Le proto répondra avec la mauvaise sans jamais le signaler.

Le tout doit ensuite tenir la charge, et le portefeuille avec. Dix utilisateurs simultanés, ce n’est pas un utilisateur multiplié par dix : la latence s’allonge, le fournisseur commence à limiter le débit, et la facture au token ne se voit pas tant qu’on est seul à cliquer. Le jour où l’API du fournisseur tombe, le proto ne bascule sur rien, il affiche une erreur.

Et il y a tout le reste, celui dont personne ne parle le samedi soir : le déploiement, Docker, la CI/CD, les secrets qui ne traînent pas dans le code, l’observabilité, le service qui redémarre seul quand il tombe.

Le mur du lundi, concrètement

Quand on ouvre le capot d’un proto qui a séduit, on retrouve à peu près toujours les mêmes trous.

Le plus fréquent : impossible de dire si la modification de mardi a cassé ce qui marchait lundi, faute du moindre test. Vient ensuite la base de données, écrite au fil de l’eau ce fameux samedi soir, qu’il va falloir faire évoluer sans perdre ce que les utilisateurs y ont mis, et dont personne n’a jamais fait de sauvegarde. Puis la question des droits : l’application a été pensée pour son auteur, alors qu’en interne ils seront quarante et n’ont pas à voir les mêmes données.

Rien de tout ça n’est insurmontable, mais rien de tout ça ne se règle en deux heures. C’est là que part l’essentiel du budget d’un vrai projet, et c’est exactement ce que la démo rend invisible.

Et il y a la gouvernance, celle que le shot fait oublier

Le DSI qui code seul le week-end, c’est déjà du shadow IT, à l’intérieur même de la DSI.

Les données qui passent dans le LLM, elles vont où ? Qui a le droit de déclencher quoi ? Qui trace les décisions de l’IA ? Et surtout, qui répond quand elle se plante sur un vrai client, un vrai contrat, une vraie donnée ?

Ces questions n’ont rien d’administratif. Elles décident de ce que vous avez le droit de mettre dans le prompt, du fournisseur que vous pouvez utiliser, et de ce que vous répondrez le jour où quelqu’un demandera pourquoi l’IA a tranché comme ça. Un proto n’a pas de gouvernance. Un système en prod, si. Et c’est souvent le plus dur, bien plus que le code lui-même.

Six mois plus tard, c’est encore un autre métier

Même en ligne, un système IA ne tient pas tout seul.

Le modèle sur lequel vous avez calé vos prompts finira par être déprécié. Son successeur ne se comportera pas exactement pareil sur vos cas limites, et sans jeu de tests métier pour le vérifier, c’est un utilisateur mécontent qui vous l’apprendra.

Le contenu vieillit aussi. De nouveaux documents arrivent, d’autres deviennent obsolètes, et un RAG qu’on ne réalimente pas se met à répondre avec les procédures de l’an dernier sans prévenir personne.

Tenir ça dans la durée, c’est une ligne de maintenance au budget, pas un projet qui se termine.

Le proto n’est pas l’ennemi

Je ne fais pas le procès du week-end. Ces deux heures valent quelque chose : elles montrent au métier quelque chose de concret plutôt qu’un slide, et elles tuent une mauvaise idée en une soirée au lieu d’un trimestre.

Le piège, c’est de confondre la preuve et le produit. Le proto répond à « est-ce que c’est possible ». Il ne dit rien de « est-ce que je peux le confier à mes équipes et à mes clients », qui est la question chère.

Ce qui a de la valeur a changé

Générer du code qui tourne, aujourd’hui, c’est presque gratuit. La machine le fait. Le shot du samedi soir, c’est la preuve que cette partie-là est devenue facile.

Du coup la valeur a glissé. Elle n’est plus dans l’écriture du code, elle est dans ce qui reste rare : le rendre solide, sûr, gouverné, déployé, et le tenir dans la durée. Pas le fantasme du truc qui tourne un an sans qu’on y touche, non. Un système surveillé, patché quand une CVE tombe, maintenu, qui ne s’écroule pas au premier imprévu. Justement ce qu’un proto du samedi soir n’aura jamais.

Et là, il faut un profil à l’intersection. Le data scientist fait de belles choses dans un notebook et n’a jamais déployé. Le vibe codeur du week-end sort un proto grisant qui meurt au premier vrai utilisateur. Moi je suis au milieu : un socle backend, du DevOps depuis l’époque de Hudson jusqu’aux GitHub Actions, et l’IA par-dessus. Je ne la fais pas juste marcher chez moi. Je la livre en état de tourner chez vous.

Vous avez un proto qui séduit en démo ?

Vous avez un proto IA qui séduit en démo mais que personne n’ose brancher en prod ?

Envoyez-le moi. Je vous fais un diagnostic gratuit de ce qui bloque vraiment : hallucinations, sécurité, gouvernance, déploiement. Vous repartez avec la liste claire des points à régler, que vous bossiez avec moi ensuite ou pas. Un échange de trente minutes suffit pour démarrer.