Votre workflow IA fonctionne en ce moment même.
Vous ne savez tout simplement pas qu'il a cessé de fonctionner il y a trois jours.
Il tourne encore. Il brûle encore des crédits API. Il produit encore des sorties que personne ne lit. L'agent que vous avez passé deux week-ends à construire produit des déchets à 0,40 $ le tas — et vous ne le découvrirez que lorsqu'un client fera une capture d'écran et vous l'enverra un mardi.
Ce n'est pas de la malchance. C'est le scénario par défaut.
Sauvegardez ceci. Vous le lirez deux fois.
Le cimetière des 30 jours
Chaque semaine, des centaines de fondateurs construisent des workflows IA et les postent sur Twitter.
La démo a l'air propre. Le fil reçoit des likes. Les réponses disent « c'est le futur ».
Trente jours plus tard, le workflow est mort.
Pas supprimé. Pas remplacé. Mort et toujours en cours d'exécution. Qui débite la carte. Qui ne produit rien d'utile. Le fondateur est passé à autre chose. L'agent n'a pas reçu le mémo.
90 % des workflows IA construits aujourd'hui ne survivront pas à leur premier mois en production. Pas parce que les modèles sont mauvais. Pas parce que les idées sont fausses. Parce que les constructeurs ont commis trois erreurs qui garantissent l'échec — et personne ne leur a dit quelles étaient ces erreurs avant qu'ils ne mettent en ligne.
Cet article est fait pour ça.
Pourquoi ils meurent
Voici l'anatomie d'une mort de workflow. C'est toujours la même séquence.
Jour 1 : Vous le construisez. Il fonctionne parfaitement dans la démo. Vous avez l'impression d'avoir débloqué quelque chose.
Jour 3 : Il fonctionne encore. Vous arrêtez de le vérifier aussi attentivement.
Jour 9 : Quelque chose change. Le format d'une réponse API se modifie légèrement. Une source qu'il lisait passe derrière un mur de connexion. Le modèle interprète un cas limite différemment qu'au jour un. La sortie se dégrade discrètement. Personne ne le remarque.
Jour 14 : Le workflow produit désormais une sortie qui est techniquement une réponse, mais substantiellement inutile. Il tourne toujours. Vous payez toujours pour cela.
Jour 23 : Un client ou un collègue mentionne que quelque chose ne va pas. Vous enquêtez. Vous trouvez 12 jours de sorties cassées que vous pensiez gérées.
Jour 30 : Vous le tuez. Vous vous dites que l'IA n'est pas prête. Vous passez à autre chose.
Le modèle ne vous a pas fait défaut. La construction a fait défaut au modèle.
Les 3 règles qui séparent les 10 % des autres
Les fondateurs dont les workflows survivent 30 jours, 90 jours, un an — ils ne sont pas plus intelligents. Ils n'ont pas de meilleurs prompts. Ils construisent avec trois règles que tout le monde ignore.
Règle 1 — Pas de description de poste, pas d'agent
La plupart des gens construisent des agents avec une intuition.
« Aide-moi avec le contenu. » « Surveille les concurrents. » « Gère les e-mails clients. »
Ce n'est pas une description de poste. C'est un vœu. Et les vœux ne survivent pas au week-end.
Une description de poste comporte cinq parties :
Ce qu'il surveille. Le déclencheur ou le calendrier spécifique. « Tous les lundis à 7h » ou « à chaque fois qu'un nouveau problème GitHub est ouvert avec l'étiquette « bug » » ou « à chaque fois qu'un e-mail arrive d'un domaine qui n'est pas dans ma liste de contacts. » Pas « parfois » ou « quand c'est pertinent. »
Ce qu'il lit. Les sources exactes. Pas « vérifie Internet. » « Extrais de ces trois flux RSS, de cette base Airtable et des 7 derniers jours de ce canal Slack. » Spécifique. Limité. Sans ambiguïté.
Ce qu'il produit. Le format de sortie exact. Pas « un résumé. » « Un briefing en trois sections : constat principal en une phrase, trois points d'appui avec une source chacun, une action recommandée. Moins de 300 mots. Dans ce Google Doc. »
Ce qu'il ne fait pas. Les barrières de sécurité. « N'envoie jamais d'e-mail externe sans approbation humaine. » « Ne modifie jamais la base de données de production. » « Ne poste jamais directement. Enregistre toujours dans les brouillons. » Les choses que vous pensez évidentes sont celles qui vous brûleront.
Comment vous savez que ça a fonctionné. La condition de succès. « Si le briefing est vide, envoie-moi un message Slack disant qu'aucune mise à jour pertinente n'a été trouvée. N'envoie pas un briefing vide. »
Les intuitions ne survivent pas au week-end. Les descriptions de poste, si.
Chaque workflow que vous construirez à partir d'aujourd'hui commence par une description de poste. Pas un prompt. Une description de poste.
Règle 2 — L'échec silencieux est le seul échec qui vous tue
Les échecs bruyants vont bien. Les échecs bruyants envoient une erreur. Ils arrêtent le workflow. Ils vous réveillent. Vous les réparez.
Les échecs silencieux sont ceux qui tuent les entreprises.
Un échec silencieux ressemble à un succès. Le workflow s'exécute. La sortie arrive. Le format est correct. Le contenu est faux — légèrement, puis plus, puis complètement — et parce que ça a l'air correct, personne ne vérifie.
Voici comment l'échec silencieux se produit en pratique :
Votre agent de contenu écrit 30 articles. Vous l'avez configuré pour programmer automatiquement ceux qui obtiennent un score supérieur à 80 sur votre grille d'évaluation interne. La grille a été calibrée sur vos 20 premiers articles. Au jour 15, le modèle commence à interpréter votre grille différemment. Les articles qui obtiennent 82 sont désormais médiocres selon votre véritable standard. Ils sont publiés quand même. Votre engagement chute. Vous blâmez l'algorithme.
Votre agent de recherche envoie un briefing hebdomadaire. Au jour 11, l'une des sources qu'il lisait change sa structure d'URL. L'agent échoue silencieusement à la récupérer. Il comble le vide avec des données en cache plus anciennes et ne signale pas l'absence. Vous lisez un briefing basé sur des informations obsolètes et prenez une décision dessus.
Votre agent de triage d'e-mails rédige des réponses. Au jour 8, il commence à catégoriser un certain type d'e-mail comme basse priorité parce que le nom de l'expéditeur correspond à un modèle dans son entraînement. Vous manquez trois e-mails importants d'un nouveau client qui partage par hasard un nom de famille avec une newsletter que vous ne lisez jamais.
Dans chaque cas : le workflow a fonctionné. Aucune erreur n'a été levée. Vous avez perdu quand même.
La solution est une vérification obligatoire des sorties. Chaque agent a besoin de trois choses :
Un champ sentinelle. Un champ dans chaque sortie qui est facile à vérifier et difficile à falsifier. Un horodatage de la source la plus récente qu'il a lue. Un compteur d'éléments traités. Un score de confiance. Quelque chose que vous pouvez parcourir en deux secondes et savoir que l'agent a réellement fait le travail.
Une alerte d'échec silencieux. Si l'agent ne produit rien, ou produit quelque chose en dessous d'un seuil, il n'envoie pas une sortie vide. Il vous envoie une alerte. « Aucun résultat trouvé ce cycle — voici ce que j'ai vérifié et pourquoi je n'ai peut-être rien trouvé. » Rien est toujours plus utile qu'un résultat vide convaincant.
Une vérification ponctuelle hebdomadaire. Choisissez une sortie par semaine par agent. Lisez-la entièrement. Comparez-la avec ce que vous auriez écrit vous-même. Cela prend quatre minutes. Cela détecte la dérive avant qu'elle ne devienne un échec.
Les agents n'échouent pas bruyamment. Construisez pour les pannes silencieuses.
Règle 3 — Votre ordinateur portable n'est pas une infrastructure
C'est là que 90 % des constructeurs meurent.
Ils construisent en local. La démo fonctionne. Ils publient le fil Twitter. Quelqu'un demande si ça tourne en production. Ils disent oui. Ce qu'ils veulent dire, c'est : ça tourne sur leur MacBook, qui est actuellement ouvert, sur leur bureau, dans leur appartement, connecté à leur WiFi domestique, et cessera de fonctionner quand ils fermeront le capot pour aller à l'aéroport jeudi.
Votre ordinateur portable n'est pas une infrastructure. C'est un environnement de développement qui se trouve exécuter quelque chose d'important en ce moment.
Voici ce qui arrive aux agents hébergés sur ordinateur portable :
macOS pousse une mise à jour à 4h du matin. La machine redémarre. L'agent s'arrête. Personne ne le sait jusqu'à lundi.
Vous fermez le capot dans un avion. Six heures de workflows manquées. L'agent de triage d'e-mails n'a pas trié. Le chasseur de bugs n'a pas chassé. L'agent de standup n'a rien envoyé.
Votre WiFi domestique tombe pendant vingt minutes. L'agent réessaie. Échoue. Passe à autre chose. Ne journalise rien. La fenêtre qu'il était censé capturer est perdue.
Vous partez en vacances. L'ordinateur reste à la maison. Tout reste à la maison avec lui.
Une vraie infrastructure fonctionne quand vous ne regardez pas. Elle fonctionne quand vous dormez, dans un avion, au dîner, injoignable pendant un week-end. Elle n'a pas besoin que vous gardiez le capot ouvert.
La règle est simple : si le workflow doit s'exécuter plus d'une fois et que vous ne pouvez pas vous permettre de manquer un cycle, il ne vit pas sur votre ordinateur portable.
Les trois options d'infrastructure qui fonctionnent réellement :
Un VPS avec un gestionnaire de processus. Un serveur à 12 $/mois faisant tourner PM2 ou Supervisor. Votre agent s'exécute comme un processus géré. S'il plante, PM2 le redémarre automatiquement. Si le serveur redémarre, PM2 le lance au démarrage. Pas cher. Fiable. Pas glamour. Ça marche.
Une plateforme d'agents gérée. Conçue spécialement pour ça. Gère les redémarrages, la surveillance, les alertes. Coûte plus qu'un VPS. Vous fait gagner les week-ends que vous passeriez à déboguer pourquoi le processus est mort. Ça vaut le coup une fois que vos agents génèrent une vraie valeur.
Sans serveur avec un planificateur. AWS Lambda ou Google Cloud Functions déclenchés par EventBridge ou Cloud Scheduler. Zéro infrastructure à gérer. Vous payez par exécution. Passe à zéro quand il ne tourne pas. Meilleure option pour les agents qui s'exécutent selon un calendrier fixe plutôt qu'en continu.
Aucune de ces options n'est compliquée. Toutes nécessitent quinze minutes de configuration. Chacune vous sauvera de la mise à jour macOS à 4h du matin qui tue vos agents et votre lundi matin.
Fermez l'ordinateur portable. Les agents doivent continuer à tourner.
Le workflow qui survit
Voici à quoi ressemble un workflow de 90 jours quand les trois règles sont appliquées.
La description de poste : Tous les lundis à 7h, lis les 7 derniers jours d'articles de ces 5 comptes concurrents et de ces 3 newsletters du secteur. Extrais les annonces de produits, les changements de prix ou les contenus ayant obtenu plus de 500 engagements. Compare avec le briefing de la semaine dernière. Signale tout ce qui est nouveau. Produis un briefing en trois sections : ce qui a changé, ce qui gagne du terrain, quelle lacune ils ont laissée. Si aucun changement n'est trouvé, envoie une alerte : « semaine calme — voici ce qui a été vérifié. » Livre sur cette page Notion et envoie une notification Slack.
Le champ sentinelle : Chaque briefing inclut : « Sources vérifiées : 8. Éléments traités : [N]. Horodatage de l'élément le plus récent : [horodatage]. » Si N est zéro ou si l'horodatage date de plus de 8 jours, il envoie une alerte au lieu d'un briefing.
L'infrastructure : Tourne sur un VPS à 12 $/mois. PM2 gère le processus. S'il plante, il redémarre en 30 secondes. Une revue hebdomadaire des logs prend 3 minutes chaque vendredi.
La vérification ponctuelle : Chaque vendredi, un briefing est lu intégralement. Prend 4 minutes. A détecté une dérive deux fois en six mois.
Ce workflow tourne depuis six mois. Il a manqué deux cycles — les deux fois, il a envoyé une alerte expliquant pourquoi. Il n'a jamais échoué silencieusement.
C'est la différence entre un workflow qui survit et un qui meurt au jour neuf.
La vérité inconfortable
La plupart des gens liront ceci, hocheront la tête et construiront leur prochain agent de la même manière que le précédent.
Un prompt. Une démo. Un fil Twitter. Trente jours de silence. Un workflow mort que personne n'a officiellement tué.
Les trois règles ne sont pas compliquées. Une description de poste prend vingt minutes à écrire. La vérification des sorties prend un champ et une condition. L'infrastructure prend quinze minutes à configurer.
L'écart n'est pas la connaissance. L'écart est de savoir si vous le faites avant de mettre en ligne ou après que le workflow a échoué.
Chaque agent que vous construisez sans description de poste est un agent que vous reconstruirez. Chaque agent sans vérification des sorties est un agent qui échouera silencieusement. Chaque agent sur votre ordinateur portable est un agent qui mourra la prochaine fois que vous fermerez le capot.
Construisez-les correctement une fois. Ils tourneront pour toujours.
Suivez @sairahul1 pour plus de guides complets sur la construction de workflows IA qui survivent au contact avec le monde réel.
TL;DR
90 % des workflows IA meurent en 30 jours. Toujours les mêmes trois raisons.
Règle 1 — Pas de description de poste, pas d'agent. Les intuitions ne survivent pas au week-end. Définissez ce qu'il surveille, lit, produit, évite et comment vous savez que ça a fonctionné. Avant d'écrire un seul prompt.
Règle 2 — L'échec silencieux est le seul échec qui vous tue. Les échecs bruyants vont bien. Les échecs silencieux ressemblent à un succès jusqu'à ce qu'un client les trouve. Intégrez un champ sentinelle, une alerte d'échec silencieux et une vérification ponctuelle hebdomadaire dans chaque agent.
Règle 3 — Votre ordinateur portable n'est pas une infrastructure. Il tourne quand le capot est ouvert. Les vrais agents tournent quand vous dormez, dans un avion, injoignable pendant un week-end. VPS, plateforme gérée ou sans serveur. Choisissez-en un. Configurez-le avant de mettre en ligne.
Les agents qui survivent ne sont pas plus intelligents. Ils sont construits correctement.
