On l’évite en pensant exploitation avant de célébrer le prototype. Une automatisation IA peut marcher lundi et devenir ingérable jeudi. Logs, versioning, accès, documentation, modularité… c’est moins sexy que la démo, mais c’est là que votre projet tient vraiment.
Besoin d'aide ? Découvrez les solutions de notre agence No Code.
C’est quoi le Day 2 Problem ?
Le Day 2 Problem, c’est tout ce qui casse après la première réussite d’un projet IA ou d’une automatisation, quand on passe de la démo à l’exploitation réelle.
Sur le moment, tout marche. Le workflow tourne. Le chatbot répond. Le reporting se génère tout seul. Tout le monde est content. Puis la vraie vie arrive : une API change, un prompt dérive, un accès expire, une personne part en congés, un modèle répond moins bien qu’avant, et personne ne sait trop où regarder.
| Day 0 | On imagine, on cadre, on planifie. On se demande ce qu’on veut automatiser, pourquoi, avec quelles données et quels risques. |
| Day 1 | On construit, on teste, on lance. C’est souvent la phase la plus visible, celle de la démo qui impressionne. |
| Day 2 | On maintient, on corrige, on surveille, on fait évoluer, on transmet. C’est là que le projet devient un vrai système. |
Construire avec un LLM, donc un grand modèle de langage comme ChatGPT, ou avec un outil no-code, c’est devenu beaucoup plus simple. Et tant mieux. Mais maintenir proprement, ça reste un vrai sujet d’ingénierie. Pas un truc réservé aux grosses DSI. Juste du bon sens opérationnel.
Il y a un fossé entre savoir inventer une solution et savoir l’exploiter dans la durée. Une IA utile, ce n’est pas seulement un prompt malin. C’est aussi de l’observabilité, c’est-à-dire savoir ce qui se passe quand ça tourne. C’est du versioning, donc garder l’historique des changements. C’est du rollback, pouvoir revenir en arrière si une modification casse tout. C’est de la documentation lisible. C’est une gestion propre des accès, des mots de passe, des droits et des données sensibles. C’est une conception modulaire, avec des blocs simples qu’on peut modifier sans tout casser.
J’ai vu des automatisations très utiles devenir un problème juste parce qu’une seule personne savait où cliquer, où était le mot de passe, ou pourquoi un prompt avait été changé. Ce n’était pas un problème d’IA. C’était un problème d’exploitation.
Le vrai sujet, ce n’est pas de ralentir l’innovation. C’est d’éviter que le prototype sympa du Day 1 devienne une dette opérationnelle au Day 2.
Pourquoi un prototype IA casse vite ?
Un prototype IA casse vite parce qu’il est souvent optimisé pour prouver que ça marche, pas pour expliquer pourquoi ça marche, ni comment réparer quand ça ne marche plus.
J’ai vu ça très concrètement sur une automatisation d’extraction de factures. Le scénario était simple et plutôt malin. L’outil lisait des PDFs, récupérait les montants, les dates, les fournisseurs, puis envoyait les données dans l’outil comptable. Au départ, tout le monde était content. C’était rapide, visible, utile. Le genre de démo qui donne envie de dire “ok, on le met en prod”.
Puis quelques factures sont parties avec de mauvais montants. Pas toutes. Juste assez pour créer un doute. Et là, on a ouvert le moteur pour comprendre. Problème classique : il n’y avait pas de logs détaillés. Juste un message final du type Automation complete.
Ce message rassure quand tout va bien. Il ne sert presque à rien quand ça casse. Parce qu’on ne sait pas ce qui s’est vraiment passé.
- Quel PDF a été traité exactement ?
- Quel champ a été extrait, et avec quelle valeur brute ?
- Quelle règle a été appliquée pour valider le montant ?
- Quelle réponse l’IA a donnée avant transformation ?
- Quelle version du prompt était utilisée ?
- À quel moment l’erreur est apparue dans la chaîne ?
Sans trace, on corrige à l’aveugle. On change un prompt, on ajoute une règle, on reteste trois PDFs à la main, puis on espère que ça ira. C’est fragile. Et souvent, on déplace juste le bug.
Le versioning pose le même souci. Le versioning, c’est simplement la capacité à garder l’historique des versions d’un système pour savoir ce qui a changé, quand, et pouvoir revenir en arrière. Si la seule version de l’automatisation est modifiée directement en production, on perd l’état stable précédent. On ne peut plus revenir proprement. On reconstruit de mémoire. Et parfois, en corrigeant l’ancien problème, on en crée un nouveau.
L’IA ne rend pas ces problèmes nouveaux. Elle les accélère. Les erreurs arrivent plus vite parce que la création va plus vite. Le prototype n’est pas le problème. Le problème, c’est de le traiter comme un produit prêt à vivre sans surveillance.
Quels garde-fous mettre avant le déploiement ?
Avant de déployer, il faut au minimum rendre l’automatisation observable, versionnée, testable et transmissible. Sinon, le vrai problème arrive le jour où ça casse, où le modèle change de comportement, ou où la seule personne qui sait relancer le truc est en congés.
Pour l’observabilité, je veux voir ce que l’automatisation fait vraiment. Pas juste “succès” ou “erreur”. Il faut logger les entrées, les sorties, les erreurs, les décisions importantes, les fichiers traités, les IDs métiers, les temps d’exécution et les appels aux modèles IA. Les bonnes pratiques qu’on utilise en DevOps et en SRE, c’est-à-dire les équipes qui fiabilisent les systèmes en production, reposent souvent sur trois familles de signaux : logs, métriques et traces. Les logs disent ce qui s’est passé. Les métriques montrent les volumes, les durées, les taux d’erreur. Les traces permettent de suivre un traitement de bout en bout.
Pour le versioning, je garde les versions des workflows, des prompts, des règles d’extraction, des mappings de champs et des paramètres du modèle. Un prompt, c’est du code métier déguisé en texte. Si vous le modifiez sans historique, vous perdez la capacité à comprendre pourquoi les résultats ont changé. Et surtout, un rollback doit être possible sans reconstruire toute l’automatisation à la main.
Pour les tests, je prends un jeu de factures représentatif. Fournisseurs différents, formats différents, PDFs propres et sales, montants ambigus, avoirs, devis, factures multi-pages. L’objectif n’est pas d’avoir un test parfait. L’objectif, c’est d’avoir un filet de sécurité avant chaque changement. Chez un client, ça a évité une mise en prod qui aurait inversé TVA et total TTC sur un fournisseur précis. Personne ne l’aurait vu en démo.
Pour les accès, je suis assez strict. Un projet ne doit pas dépendre du compte personnel d’une seule personne. Il faut des comptes de service, des droits maîtrisés, une gestion propre des secrets, comme les clés API ou mots de passe, et une séparation claire entre ce qui appartient à l’utilisateur et ce qui appartient au système.
Pour la documentation, pas besoin d’un roman. Il faut savoir qui possède le workflow, où il tourne, comment le relancer, quels systèmes il touche, comment lire les erreurs, qui prévenir, et quelles limites sont connues.
| Risque | Symptôme | Garde-fou |
| Automatisation opaque | Personne ne sait pourquoi une facture a été rejetée | Logs, métriques, traces et IDs métiers |
| Changement non maîtrisé | Le résultat IA change après une modification de prompt | Versioning des prompts, workflows, règles et paramètres |
| Régression invisible | Un cas fournisseur casse après une mise à jour | Jeu de tests représentatif avant chaque changement |
| Dépendance à une personne | Le workflow tombe quand un compte est désactivé | Comptes de service, droits maîtrisés et secrets sécurisés |
| Maintenance impossible | Personne ne sait relancer ou diagnostiquer | Documentation courte, utile et à jour |
Comment rendre l’automatisation scalable ?
Une automatisation devient scalable quand elle n’est plus câblée pour un seul cas, une seule boîte mail, un seul fournisseur, un seul site ou une seule personne.
Le piège classique, c’est le hardwire, ou câblage en dur. Ça veut dire qu’on met directement dans le scénario des éléments fixes : une adresse mail précise, trois noms de fournisseurs, un chemin de fichier local, une connexion comptable liée au compte de la personne qui a créé l’automatisation. Sur le moment, ça marche. Même très bien parfois. Puis un deuxième site veut l’utiliser, et là tout se complique.
Il faut dupliquer le scénario, changer les accès, adapter les formats, retester à la main, refaire deux exceptions, puis trois autres. On croit scaler, mais en fait on empile des copies fragiles. J’ai vu ça souvent : l’automatisation gagne du temps au début, puis elle crée une dette opérationnelle énorme.
Ce que je cherche à faire à la place, c’est séparer la logique métier de la configuration. La logique dit quoi faire. La configuration dit pour qui, avec quels paramètres, quels fournisseurs, quels seuils, quels accès.
- Je stocke les paramètres par site, entité ou pays, au lieu de les écrire dans le scénario.
- Je traite les fournisseurs comme des cas configurables, pas comme des exceptions bricolées dans tous les sens.
- Je prévois les erreurs attendues : facture illisible, montant incohérent, fournisseur inconnu, donnée manquante.
- Je garde une file d’attente ou une zone de validation humaine pour les cas incertains.
- Je logue ce qui se passe, parce qu’un bug sans trace, c’est juste une perte de temps déguisée.
La gouvernance doit aussi être claire, mais légère. Pas besoin d’un comité de 12 personnes. Il faut juste savoir qui valide une modification, qui surveille les erreurs, qui reçoit les alertes, qui décide qu’un nouveau fournisseur est supporté, qui peut modifier un prompt. Un prompt, c’est l’instruction donnée à l’IA. Si n’importe qui peut le changer sans suivi, vous avez une automatisation instable.
Chez des clients, le vrai déclic arrive souvent quand on passe d’une automatisation utile à dix automatisations en production. Là, les petites approximations deviennent visibles. Les logs manquants, les accès personnels, les versions non suivies et l’absence de propriétaire coûtent plus cher que le temps gagné au début.
Rendre une automatisation scalable, ce n’est pas la rendre énorme. C’est la rendre compréhensible, déplaçable, réparable et améliorable sans dépendre d’un héros interne.
Votre projet IA peut-il vraiment tenir lundi prochain ?
Le Day 2 Problem, c’est le moment où l’enthousiasme du prototype rencontre la vraie vie. Les factures changent, les formats bougent, quelqu’un part en congé, un prompt est modifié, une erreur passe sans trace. Rien de spectaculaire au départ, juste une accumulation de petits angles morts.
Je ne dis pas qu’il faut transformer chaque automatisation IA en usine à gaz. Je dis qu’il faut prévoir le minimum vital : logs, versions, rollback, accès propres, documentation courte, tests réalistes et conception modulaire. Avec ça, vous gardez la vitesse du no-code et de l’IA, sans créer une bombe opérationnelle. Le bénéfice pour vous est simple : moins de stress, moins de dépendance, plus de projets IA qui durent.
FAQ
- Qu’est-ce que le Day 2 Problem dans un projet IA ?
Le Day 2 Problem désigne les problèmes qui apparaissent après le lancement initial : maintenance, erreurs invisibles, absence de logs, versioning flou, accès mal gérés, documentation absente. En clair, c’est le moment où une automatisation IA passe de démo sympa à système qu’il faut exploiter pour de vrai. - Pourquoi les automatisations IA cassent après le lancement ?
Elles cassent souvent parce qu’elles ont été construites pour fonctionner sur un cas précis, pas pour gérer les variantes, les erreurs et les changements. Un nouveau format de facture, un prompt modifié, un accès expiré ou un fournisseur différent peut suffire à créer un incident si rien n’a été prévu. - Quels logs faut-il suivre dans une automatisation IA ?
Je conseille de tracer les fichiers ou données reçus, les étapes exécutées, les réponses du modèle IA, les champs extraits, les erreurs, les temps d’exécution et les systèmes appelés. Le but n’est pas de tout stocker n’importe comment. Le but est de pouvoir comprendre rapidement ce qui s’est passé quand un résultat est faux. - Le no-code augmente-t-il le risque de Day 2 Problem ?
Le no-code n’est pas le problème. Il permet d’aller très vite, et c’est une force. Le risque vient surtout du manque de pratiques d’exploitation autour : pas de versioning, pas de rollback, pas de propriétaire clair, pas de documentation, pas de tests. Un workflow no-code peut être robuste s’il est conçu avec ces réflexes. - Comment savoir si mon projet IA est prêt pour la production ?
Posez quelques questions simples : est-ce que je peux comprendre une erreur ? revenir à une version précédente ? transmettre la maintenance à quelqu’un d’autre ? gérer plusieurs cas métier ? sécuriser les accès ? tester avant de modifier ? Si la réponse est non sur plusieurs points, le projet peut marcher aujourd’hui, mais il n’est pas encore prêt pour le Day 2.
A propos de l’auteur
Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, Analytics Engineering, automatisation no/low code avec n8n, intégration de l’IA en entreprise et SEO/GEO. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. J’accompagne des équipes chez Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football, Texdecor et d’autres sur des sujets très concrets : fiabiliser les données, automatiser proprement, industrialiser sans perdre le contrôle. Si vous voulez mettre vos projets IA ou automatisations à plat avant qu’ils cassent en production, contactez-moi.
⭐ Analytics engineer, Data Analyst et Automatisation IA ⭐
- Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…
Mon terrain de jeu :
- Data Analyst & Analytics engineering : tracking avancé (GA4, Matomo, Piano, GTM server, Tealium, Commander Act, e-commerce, CAPI, RGPD), entrepôt de données (BigQuery, Snowflake, PostgreSQL, ClickHouse), modèles (Airflow, dbt, Dataform), dashboards décisionnels (Looker, Power BI, Metabase, SQL, Python).
- Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
- Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.