Un article du Journal du Net posait récemment un constat que je trouve juste : l’IA accélère la production de code et fabrique en même temps une dette de complexité, faite de dépendances opaques, de modules que personne n’a relus et de logique qu’on ne sait plus expliquer six mois plus tard. La même semaine, ZDNet racontait comment son auteur avait sorti une application fonctionnelle en deux jours avec un outil gratuit et open source. Les deux articles disent la vérité. Ils décrivent juste deux moments différents de la même histoire.
La partie visible, c’est la vitesse. Vous décrivez ce que vous voulez, l’outil produit quelque chose qui tourne, vous ajustez, et le vendredi soir vous avez un formulaire de demande de devis connecté à votre boîte mail, ou un tableau de suivi des adhésions, ou un petit script qui relance les factures impayées. Sincèrement, c’est un progrès. Il y a cinq ans, la même chose demandait un budget que la plupart des structures que je croise n’ont pas.
La partie invisible arrive plus tard. Elle arrive le jour où l’outil casse.
Ce qui se passe quand une automatisation générée par IA tombe en panne
Une automatisation ne s’arrête presque jamais pour une raison spectaculaire. Un fournisseur change son API. Un service exige désormais une authentification différente. Une bibliothèque n’est plus maintenue. Le format d’un export passe de point-virgule à virgule. Rien de dramatique en soi, sauf que le jour où ça arrive, quelqu’un doit ouvrir le capot.
Et là, la question n’est pas « est-ce que le code est bon ». La question est « est-ce que quelqu’un dans cette structure comprend ce que fait ce truc ». Si la réponse est non, vous avez deux options, toutes les deux coûteuses : payer quelqu’un pour reconstituer une logique qu’il n’a pas écrite, ou tout refaire. Refaire est souvent moins cher. C’est précisément ce qui devrait alerter.
Le piège est particulièrement vicieux pour les petites structures, parce que l’outil bricolé en deux jours devient rarement un brouillon. Il devient le formulaire par lequel arrivent les demandes clients. Il devient le fichier sur lequel s’appuie la trésorerie. Il passe de prototype à infrastructure sans que personne ne prenne la décision consciente de ce passage.
Le critère qui sépare un usage jetable d’un usage durable
Je m’en tiens à une règle simple, et je l’assume comme un avis personnel plutôt que comme une vérité générale : la durée de vie prévue détermine le niveau d’exigence.
Un script qui nettoie un fichier Excel une fois, pour préparer une facturation annuelle, peut être généré, utilisé et jeté. Personne n’a besoin de le comprendre. S’il casse l’année prochaine, on en refait un.
Un processus qui tourne toutes les semaines et sur lequel repose une partie de votre activité change de catégorie. Là, la génération assistée reste utile pour aller vite, mais quelqu’un doit pouvoir raconter ce que fait le flux, étape par étape, à voix haute, sans regarder le code. Si vous ne pouvez pas le raconter, vous ne le possédez pas. Vous l’hébergez.
Entre les deux, il y a une zone grise que je tranche toujours du même côté : dans le doute, on considère que ça va durer. Les choses temporaires ont une espérance de vie remarquable.
Les vérifications avant de mettre en service une automatisation assistée par IA
Voici ce que je regarde, dans l’ordre, avant de considérer qu’une automatisation peut tourner sans surveillance.
D’abord, où vivent les données. Un flux qui fait transiter des noms, des adresses, des coordonnées d’adhérents ou de patients par trois services successifs mérite qu’on sache lesquels, et où sont leurs serveurs. C’est un des arguments en faveur des outils qu’on héberge soi-même, comme n8n, qui vient d’ailleurs d’ajouter un assistant conversationnel pour construire les flux : les données restent dans votre environnement.
Ensuite, la liste des dépendances. Combien de comptes tiers font fonctionner ce truc, et que se passe-t-il si l’un d’eux change de tarif ou ferme. Une automatisation qui repose sur six services gratuits est une automatisation qui a six raisons de tomber.
Ensuite, le comportement en cas d’échec. Est-ce que le flux prévient quelqu’un quand il échoue, ou est-ce qu’il échoue en silence. C’est le point que je vois le plus souvent manquant, et c’est le plus grave. Une automatisation qui s’arrête bruyamment vous coûte une demi-journée. Une automatisation qui s’arrête discrètement vous coûte les trois semaines pendant lesquelles vous avez cru qu’elle tournait.
Enfin, la sortie de secours. Si tout s’arrête demain matin, quel est le geste manuel qui prend le relais. Il doit tenir en une phrase et être connu d’au moins deux personnes.
Documenter un flux en une page, concrètement
Je ne demande à personne d’écrire une documentation technique. Une page suffit, rédigée en français, écrite au moment où le flux est encore frais dans la tête.
Elle contient ce que le flux déclenche et quand, la liste des comptes et services impliqués avec l’adresse mail sous laquelle ils ont été créés, ce que la personne doit faire si elle reçoit une alerte d’erreur, et le nom de celui qui a construit la chose. Ajoutez la date. Dans dix-huit mois, savoir si un flux date d’avant ou après votre changement d’outil de facturation vous fera gagner une heure.
Cette page se range là où on la retrouvera, c’est-à-dire pas dans les favoris du navigateur de la personne qui partira. Un dossier partagé, un document épinglé, peu importe, du moment qu’un nouveau venu tombe dessus sans le chercher.
Ce travail prend vingt minutes. Il est fastidieux, il n’a rien de gratifiant, et c’est exactement ce qui fait la différence entre une automatisation qui vous sert et une automatisation qui vous tient.
Mon avis sur les outils qui génèrent une application en deux jours
Je les trouve très bons pour trois choses : explorer une idée avant d’y investir, remplacer une tâche répétitive strictement interne, et comprendre ce qu’on veut vraiment avant d’en parler à quelqu’un. Arriver avec un prototype bancal mais parlant vaut mieux qu’arriver avec un cahier des charges flou.
Je m’en méfie dès que le résultat touche vos clients, vos adhérents ou vos usagers. Pas par principe, mais parce que la qualité générée est irrégulière sur les sujets qui ne se voient pas à l’usage : la gestion des erreurs, la sécurité des formulaires, l’accessibilité, le comportement sur un vieux téléphone. Ces choses-là ne se manifestent pas pendant la démonstration. Elles se manifestent devant la personne qui n’arrive pas à vous envoyer sa demande.
Et je dis aussi ce que je ne fais pas : je ne reprends pas volontiers un projet généré entièrement par IA sans relecture, quand il est déjà en production et qu’il porte des données réelles. Ce n’est pas un refus de principe, c’est une question honnête de coût. Reconstituer une intention à partir d’un code que personne n’a lu prend souvent plus de temps que de repartir sur des bases claires, et je préfère le dire avant plutôt que de facturer l’archéologie.
Par où reprendre la main sur vos automatisations cette semaine
Listez ce qui tourne déjà chez vous sans que personne ne le regarde. Les scripts, les flux, les petits outils, les feuilles de calcul avec des formules que seul un ancien collègue comprenait. Pour chacun, posez la seule question qui compte : si ça s’arrête jeudi, qu’est-ce que ça casse et qui sait le réparer.
Ceux qui ne cassent rien, laissez-les vivre. Ceux qui cassent quelque chose, documentez-les en une page. Ceux qui cassent quelque chose et que personne ne comprend, mettez-les en haut de la pile : ce sont vos vraies urgences, même s’ils fonctionnent parfaitement aujourd’hui.
C’est le genre de tri que je fais avec les structures que j’accompagne sur l’automatisation et l’IA pour petites structures, généralement avant de construire quoi que ce soit de nouveau. On enlève souvent plus qu’on n’ajoute, et le résultat tient mieux dans le temps.
L’IA a rendu la construction presque gratuite. Elle n’a rien changé au coût de la compréhension, et c’est celui-là qu’on paie sur la durée.