L’IA la plus utile n’a parfois aucune fenêtre de chat.
Elle reçoit une inscription, met un profil à jour, attend qu’un état change, rassemble des informations, prépare un dossier, transforme un article validé ou signale une variation dans Search Console. Dans ces workflows, l’utilisateur ne voit pas un modèle. Il voit le travail avancer et la bonne personne intervenir au bon moment.
C’est cette couche moins visible que nous construisons chez IZZY. Pas des démonstrateurs qui répondent à trois questions préparées, mais des workflows reliés aux outils, aux règles et aux responsabilités de l’entreprise.
Nous présentons ici quatre systèmes utilisés dans des opérations réelles. Havana Club est nommé ; les autres contextes clients sont volontairement anonymisés. Nous expliquons la mécanique utile, les décisions de conception et les limites. Nous ne publions ni identité, ni donnée confidentielle, ni résultat chiffré que nous ne pouvons pas établir.
L’essentiel en 60 secondes
Les quatre systèmes couvrent des problèmes très différents :
- Activation et suivi des utilisateurs : n8n relie une file d’attente, un CRM Notion, des règles de classement, des rappels et plusieurs profils applicatifs.
- Présélection d’opportunités : un workflow répartit la collecte, l’OCR, la structuration et l’évaluation entre des modèles spécialisés, puis produit une première classification à partir d’une liste confidentielle de questions avant la revue humaine.
- Production éditoriale : un framework transforme un article préparé par un éditeur en paquet de publication complet, avec structure, médias et métadonnées.
- Pilotage Search Console post-migration : chaque semaine, une chaîne automatisée compare le relevé courant à tout l’historique, produit le rapport, puis le soumet à un spécialiste SEO avant envoi.
Le point commun n’est pas un modèle particulier. C’est une architecture d’exploitation :
événement → état fiable → règles → interprétation éventuelle → action → trace → exception
L’IA intervient lorsqu’il faut interpréter, résumer ou comparer. Les règles déterministes restent préférables lorsqu’une condition simple suffit. Et une personne garde la responsabilité des critères, des exceptions et des décisions qui engagent l’entreprise.
Dans cet article
- Commencer par le travail qui se perd entre les outils
- Transformer une file d’attente en parcours d’activation
- Automatiser la collecte sans automatiser le verdict
- Automatiser l’atelier de publication, pas la ligne éditoriale
- Transformer Search Console en système d’observation continu
- Quatre systèmes, une même architecture
- Comment choisir le premier workflow à automatiser
1. Commencer par le travail qui se perd entre les outils
Une entreprise formule rarement son problème ainsi : « Il nous faut un workflow orchestré avec des états persistants et une couche LLM. »
Elle décrit plutôt l’un de ces symptômes :
- des inscrits présents dans Notion sans état clair pour la prochaine relance ;
- trop de temps consacré à réunir les informations avant de comparer les dossiers ;
- un article validé encore loin de sa mise en ligne ;
- des données Search Console disponibles, mais un rapport trop tardif pour guider la prochaine décision.
Le problème se trouve dans les passages : entre un formulaire et le CRM, entre une source publique et une grille d’analyse, entre un document éditorial et le site, entre une métrique et l’action qu’elle mérite.
C’est pourquoi nous ne commençons pas par demander quel modèle utiliser. Nous cartographions d’abord six éléments :
| Élément | Question à trancher |
|---|---|
| Déclencheur | Quel événement met réellement le processus en mouvement ? |
| État | Où sait-on ce qui est déjà fait, attendu, bloqué ou terminé ? |
| Source fiable | Quel système détient l’information qui gouverne l’action ? |
| Règle | Quelle condition peut être exécutée sans interprétation ? |
| Jugement | À quel endroit une synthèse, une comparaison ou une décision humaine devient-elle nécessaire ? |
| Exception | Qui intervient lorsque l’entrée manque, se contredit ou sort du cadre ? |
Parfois, la bonne réponse tient dans une intégration et quelques règles. Ajouter un LLM ne la rendrait ni plus fiable ni plus utile. Dans d’autres cas, le volume et l’hétérogénéité des informations justifient une couche d’interprétation. Notre travail consiste à placer cette couche au bon endroit, puis à rendre le reste observable.
2. Transformer une file d’attente en parcours d’activation
Une inscription est un événement. Ce n’est pas encore une relation active.
Dans l’un des workflows que nous opérons, le parcours a été automatisé dès le premier jour. Les personnes rejoignent une file depuis des liens diffusés dans une newsletter, des live streams et des groupes WhatsApp ou Telegram. Elles apparaissent ensuite dans Notion, utilisé ici comme CRM opérationnel.
Le besoin n’était pas de remplacer une ancienne tâche manuelle. Il fallait relier dès le départ les dossiers prospects et leads, les informations de paiement, les abonnements à la newsletter, les comptes de la communauté et les comptes du site produit. Dans ce cas précis, une personne est considérée comme activée lorsqu’elle a terminé le parcours, répondu aux questions attendues et acheté le produit.
Le parcours automatisé
Le workflow s’organise en cinq mouvements.
1. Créer le dossier
Lorsqu’une personne s’inscrit, son dossier rejoint Notion. Les informations qu’elle a volontairement fournies deviennent des champs structurés utilisables par la suite du parcours.
2. Préparer la priorité de traitement
n8n collecte les données utiles à l’étape suivante et applique les critères définis pour le processus. Le classement ne constitue pas un jugement général sur la personne. Il sert à organiser le traitement selon des règles métier explicites que le propriétaire du parcours doit pouvoir expliquer et modifier.
3. Piloter les rappels par l’état
Le système ne se contente pas d’envoyer une séquence identique à tout le monde. Il vérifie si l’action attendue a été réalisée. Tant que l’état reste ouvert, il peut programmer le prochain rappel selon les règles du parcours. Lorsque l’action est accomplie, la branche de relance s’arrête.
4. Synchroniser les profils
Le dossier Notion ne vit pas seul. D’autres services détiennent leurs propres profils ou états. n8n propage les changements nécessaires pour éviter qu’une personne apparaisse « à relancer » dans un outil et « activée » dans un autre.
5. Garder un chemin humain pour les modifications manuelles
Le chemin d’exception confirmé concerne une modification manuelle de l’état, par exemple lors d’un remboursement. Les autres incidents et mécanismes de reprise n’ont pas été documentés pour cet article ; nous ne prétendons donc ni qu’un type de panne est fréquent, ni que le système n’en connaît aucune.
Le système peut se résumer ainsi :
point d’entrée → inscription → dossier CRM → données structurées → priorité → rappel conditionnel → réponses → achat → synchronisation
Ce que l’automatisation ne doit pas décider seule
Le workflow exécute le parcours. Il ne définit pas sa légitimité.
Une personne reste responsable :
- de l’action que l’utilisateur est réellement invité à accomplir ;
- des critères utilisés pour organiser les dossiers ;
- de la fréquence et de l’arrêt des rappels ;
- des données autorisées dans chaque service ;
- des situations dans lesquelles un contact humain remplace l’automatisation.
Lorsque des données personnelles sont impliquées, les accès, la conservation et la finalité doivent être cadrés pour le processus réel. Notre guide sur les accès et autorisations des agents IA explique comment relier une connexion à une mission, un propriétaire et une procédure d’arrêt.
La valeur de ce type de système n’est pas « envoyer plus de messages ». Elle consiste à donner au parcours un état exploitable : savoir qui attend quoi, quel événement arrête l’automatisation et où une exception demande une décision.
La partie 2 de ce guide, Ce funnel n’a jamais été manuel, décrit ce parcours en détail.
3. Automatiser la collecte sans automatiser le verdict
Le deuxième système sert à présélectionner des startups technologiques internationales pour une activité de capital-risque. L’organisation, sa géographie, sa stratégie et le contenu exact de sa grille restent anonymisés.
La question automatisée n’est pas « faut-il investir ? ». Elle est plus étroite : « ce dossier mérite-t-il le temps d’une analyse humaine plus approfondie ? »
Le travail manuel demandait de réunir des informations dispersées, de les analyser puis de les vérifier une à une contre les mêmes critères. Le workflow transforme ces vagues d’information en dossiers comparables, tout en conservant la différence entre une donnée publique, une affirmation fournie par la startup, une interprétation de modèle et la décision humaine.
Première étape : enrichir un dossier minimal
Le processus commence avec une fiche structurée contenant les informations initiales disponibles. Une automatisation recherche ensuite des signaux dans les sources publiques autorisées, principalement X ainsi que les autres présences publiques utiles au périmètre.
Chaque information utile rejoint un champ prévu à cet effet. La provenance doit rester identifiable. Une phrase promotionnelle trouvée sur un site ne devient pas un fait indépendant parce qu’elle a été copiée dans le CRM.
Deuxième étape : intégrer les documents reçus
Lorsqu’un projet fournit ensuite des informations plus complètes, les documents sont analysés selon une structure définie à l’avance. Le système extrait les éléments correspondant aux critères attendus et les ajoute au dossier sans effacer les signaux déjà collectés.
Cette séparation compte. Elle permet de voir :
- ce qui vient d’une source publique ;
- ce que le projet affirme lui-même ;
- ce qui manque encore ;
- ce qui semble se contredire ;
- ce qui relève déjà d’une interprétation.
Troisième étape : attribuer une fonction précise à chaque modèle
Dans la configuration actuelle, plusieurs modèles provenant de fournisseurs différents sont sélectionnés en fonction de leur adéquation à une tâche précise. Ils ne produisent pas des analyses concurrentes : ils se complètent dans une même chaîne.
- un modèle analyse les signaux provenant de X ;
- un autre traite les autres sources publiques ;
- un modèle spécialisé prend en charge l’OCR des documents fournis, notamment le pitch deck ;
- un dernier applique le cadre d’évaluation au dossier structuré et prépare la classification finale.
Le choix d’un autre modèle ne transforme pas une affirmation en preuve. La provenance, les documents originaux et les inconnues doivent rester visibles à travers toute la chaîne.
Quatrième étape : répondre à une liste de questions avant le relais humain
La grille exacte est confidentielle. Elle contient une liste de questions auxquelles le système doit répondre par « oui », « non » ou « possible ». Une question à laquelle le dossier ne permet pas de répondre est enregistrée comme manquante, sans être forcée dans l’une des trois réponses. L’ensemble des réponses produit à son tour une première classification dans ces trois catégories.
Cette classification ne constitue ni une recommandation d’investissement ni une due diligence. Elle sert à décider si le dossier mérite une analyse humaine plus approfondie. Lorsque la réponse est positive ou suffisamment incertaine pour justifier l’examen, une personne reprend le dossier.
La chaîne utile ressemble donc à ceci :
profil initial → sources publiques → OCR du pitch deck → dossier structuré → réponses bornées → classification initiale → analyse humaine
Ce que l’automatisation apporte, c’est une discipline de présélection. Elle réduit la part du travail consacrée à chercher, déplacer et reformater l’information. Elle ne transforme pas une grille interne en vérité universelle et ne prend pas la décision d’investir.
La partie 3, Des jours aux minutes, détaille le préscreening étape par étape.
4. Automatiser l’atelier de publication, pas la ligne éditoriale
Un article peut être validé sur le fond et rester loin de la publication.
Il faut encore appliquer la structure du site, traiter les images, vérifier les noms de fichiers, produire les métadonnées, choisir une catégorie, préparer les formats attendus et contrôler que le paquet final est complet. Répété à chaque publication, ce travail devient une taxe de production. Réalisé à la hâte, il crée des oublis qui n’améliorent ni le contenu ni l’expérience du lecteur.
Le Content Publication Framework d’IZZY automatise cette couche.
Il commence après la décision éditoriale
Le système ne reçoit pas l’instruction vague « écris quelque chose sur l’IA ». Il part d’un article, d’une analyse ou d’une recherche préparés par un éditeur. Le format d’entrée n’est pas figé : les blocs essentiels - introduction, corps du texte, conclusion, verdict ou équivalent - doivent être présents.
L’équipe a déjà défini :
- le sujet ;
- le lecteur ;
- l’angle ;
- les sources et les preuves ;
- la conclusion que la marque peut défendre.
Le framework connaît plusieurs contrats de contenu : actualité, analyse, article de recherche et autres formats définis par le système éditorial. Chaque contrat précise la structure attendue et les éléments nécessaires à la publication.
Il transforme le contenu en paquet publiable
Selon le contrat sélectionné, le système peut :
- convertir l’article dans la structure technique attendue par le site ;
- normaliser les champs et éléments de navigation ;
- convertir les images en WebP et les adapter à leur emplacement ;
- proposer les métadonnées manquantes, notamment les textes alternatifs ;
- vérifier la présence des fichiers et champs obligatoires ;
- produire puis publier le contenu dans le format attendu par le site.
Un LLM peut proposer un texte alternatif à partir de ce qui est réellement visible dans l’image. Il ne doit pas inventer un produit, une personne ou un contexte absent. Plus largement, le framework ne complète pas silencieusement une partie obligatoire : si les données nécessaires manquent, la validation échoue.
Le contrôle humain précède le mode automatique
Le parcours actuel passe par une interface web. La personne qui importe le contenu traverse plusieurs étapes de validation et accepte ou refuse les modifications proposées. Tant que ces décisions ne sont pas prises, le système ne bascule pas en autonomie.
Une fois l’ensemble approuvé, le traitement et la publication se poursuivent automatiquement. Chaque état du contenu est versionné, ce qui permet de revenir à un état antérieur au lieu d’écraser silencieusement la dernière version fiable.
La chaîne devient :
import éditorial → contrôle des blocs obligatoires → transformation → médias WebP adaptés à l’emplacement → propositions → validations humaines → traitement et publication automatiques → état versionné
Ce que le framework ne remplace pas
Il ne décide pas pourquoi un sujet mérite d’être publié. Il ne possède pas l’expérience racontée. Il ne transforme pas une source faible en preuve. Il ne prend pas la responsabilité d’une affirmation.
Le gain recherché vient de la répétabilité de la production, pas de l’effacement de l’éditeur. C’est aussi la raison pour laquelle nous distinguons toujours automatisation et autorité avant le passage en production.
La partie 4, L’article est validé. Pourquoi n’est-il toujours pas publié ?, présente le framework de bout en bout.
5. Transformer Search Console en système d’observation continu
Le site de Havana Club venait d’être reconstruit. Sa structure avait changé. Le besoin n’était pas de remplacer un ancien rapport manuel - il n’en existait pas - mais d’installer dès la migration une lecture régulière de la récupération organique.
Le workflow Search Console construit par IZZY s’exécute une fois par semaine. Il récupère le relevé courant, le compare à tous les relevés précédents, produit les graphiques et génère un rapport à partir des règles définies dans le brief. Une couche LLM réalise automatiquement l’analyse et la rédaction.
Avant l’envoi au client, un spécialiste SEO lit le document, le simplifie si nécessaire et le valide. Dans la plupart des cas, cette revue prend 15 à 25 minutes.
La collecte suit un contrat stable
Chaque semaine, le système interroge les données autorisées et conserve les dimensions nécessaires au rapport : dates, pages, requêtes ou segments retenus pour le périmètre.
L’API Search Analytics de Google permet de requêter les performances avec des filtres et des dimensions, puis retourne notamment clics, impressions, CTR et position moyenne. Google précise aussi que l’API ne garantit pas toutes les lignes et privilégie certaines données, et que les données récentes peuvent rester incomplètes. Une automatisation sérieuse doit conserver ces limites au lieu de transformer une extraction partielle en certitude. Voir la documentation officielle.
L’historique rend les variations comparables
Le système archive les données et leur contexte méthodologique : propriété, période, dimensions, filtres et état des données. Le relevé courant est comparé à tout l’historique, pas seulement à la semaine précédente. Le rapport montre ainsi où se situe le site dans sa trajectoire depuis la migration.
Le rapport possède un noyau stable
| Section | Rôle |
|---|---|
| Summary | Donner la lecture essentielle de la semaine |
| Per-property snapshot | Montrer l’état de chaque propriété suivie |
| Migration recovery trends | Situer le relevé dans la récupération post-migration |
| Action plan | Prioriser les vérifications et les actions |
Des sections supplémentaires peuvent apparaître selon les données. Le premier défaut rencontré n’a d’ailleurs pas été un faux signal : certains rapports donnaient trop d’informations, de manière trop complexe. Il a fallu apprendre au système à hiérarchiser et simplifier. Dans un reporting automatisé, la surcharge est aussi un mode d’échec.
« 100 % automatique » ne signifie pas « 100 % certain »
La collecte, la comparaison historique, la visualisation, l’analyse et la rédaction du brouillon fonctionnent automatiquement. Cela ne rend pas chaque explication correcte et ne déclenche pas un envoi sans contrôle.
Une recommandation automatisée peut signaler une page à examiner. Elle ne doit pas réécrire silencieusement le site ou attribuer une variation au premier récit plausible. Le spécialiste SEO reste responsable de la validation et de l’action qui suit. Les 15 à 25 minutes décrivent son temps de revue habituel, pas une mesure avant/après de l’économie réalisée.
La chaîne complète ressemble à ceci :
extraction hebdomadaire → historique complet → tendances de récupération → rapport LLM → simplification → validation SEO → envoi client
La partie 5, Après une migration de site, détaille le workflow de reporting et les limites des données Search Console.
6. Quatre systèmes, une même architecture
Ces quatre histoires ne partagent ni le même utilisateur, ni les mêmes données, ni la même conséquence. Elles partagent une discipline de conception.
| Couche | Rôle | Exemple |
|---|---|---|
| Déclencheur | Commencer au bon événement | Inscription, nouveau document, article validé, extraction planifiée |
| État | Savoir où se trouve le travail | Profil en attente, dossier incomplet, contenu approuvé, période analysée |
| Source | Conserver l’information gouvernante | CRM, document reçu, article éditorial, données Search Console |
| Règles | Exécuter ce qui est explicite | Arrêt d’un rappel, champ requis, structure de fichier, période de comparaison |
| Interprétation | Utiliser un LLM lorsque le sens compte | Synthèse, comparaison, métadonnée proposée, recommandation initiale |
| Action | Produire un changement borné | Synchroniser, préparer, générer un paquet, signaler une anomalie |
| Preuve et reprise | Comprendre et corriger | Source, journal, statut, divergence, responsable, retour manuel |
Trois règles résument notre approche.
Les règles avant les modèles
Si une condition peut être exprimée clairement, elle doit rester déterministe. Un LLM n’a pas besoin de décider si un champ obligatoire est vide ou si une date est dépassée. Notre checklist de gouvernance IA du pilote à la production utilise la même distinction entre humain, déterministe, assistant et agent pour choisir le mécanisme adapté à chaque workflow.
L’état avant le prompt
Un bon prompt ne compense pas un système qui ignore ce qui a déjà été fait. Les dossiers, statuts, versions et sources doivent survivre à une exécution et pouvoir être relus.
L’exception avant l’échelle
La question n’est pas seulement « que fait le workflow lorsqu’il réussit ? ». C’est « que voit l’équipe lorsqu’il manque une donnée, que deux outils se contredisent ou que le fournisseur change ? ».
C’est la différence entre une automatisation impressionnante en démonstration et un système que l’entreprise peut réellement exploiter.
7. Comment choisir le premier workflow à automatiser
Ne commencez pas par le processus le plus visible. Commencez par celui dont la frontière peut être comprise et mesurée.
Posez sept questions :
- Le travail revient-il assez souvent pour justifier un système ?
- Traverse-t-il plusieurs outils, équipes ou états ?
- L’entrée fiable et le résultat attendu peuvent-ils être nommés ?
- Les règles simples peuvent-elles être séparées des tâches d’interprétation ?
- Une erreur peut-elle être détectée, arrêtée et reprise ?
- Une personne possède-t-elle le processus et ses exceptions ?
- Disposez-vous d’une situation de référence pour comparer le temps, les reprises, les échecs ou la qualité ?
La réponse ne doit pas toujours être « construire ».
| Situation | Première décision utile |
|---|---|
| Règles et états clairs, volume récurrent | Cadrer un pilote borné |
| Processus différent selon chaque personne | Cartographier et stabiliser avant d’automatiser |
| Condition simple entre deux services | Utiliser une intégration déterministe, sans LLM |
| Sources contradictoires ou non détenues | Réparer l’autorité et la provenance |
| Conséquence juridique, financière ou humaine élevée | Ajouter une validation et le spécialiste compétent |
| Aucun propriétaire des exceptions | Ne pas passer en autonomie |
Conclusion : un système IA exploitable est un système que l’équipe peut expliquer
Une automatisation utile ne se mesure pas au nombre de modèles, de nœuds ou d’outils connectés. Elle se reconnaît à des questions plus simples.
L’équipe sait-elle ce qui déclenche le travail ? Où se trouve l’état fiable ? Quelle règle s’applique ? Qu’est-ce que le modèle interprète réellement ? Que se passe-t-il si le résultat manque ou se trompe ? Qui peut arrêter le système ?
Dans les quatre systèmes présentés ici, l’IA n’efface pas le processus. Elle prend en charge une partie précise du mouvement : préparer, rapprocher, structurer, comparer ou signaler. La décision qui engage l’entreprise reste attribuée.
Apportez un workflow qui traverse trois outils
Apportez-nous un processus récurrent, les outils qu’il traverse, l’action attendue et une exception récente. Lors d’un appel de cadrage, IZZY peut examiner le plus petit système utile : règles n8n, couche LLM, intégration plus simple, étape humaine renforcée - ou aucun build si le processus n’est pas prêt.
C’est exactement le périmètre de notre service Automatisation IA n8n.
Questions fréquentes
Non. n8n orchestre des événements et des actions entre les systèmes. Le CRM ou un autre outil métier reste responsable des enregistrements que l’équipe y maintient. L’automatisation doit préciser quel système gouverne chaque état.
n8n convient à l’orchestration, aux règles, aux déclencheurs et aux intégrations. Un LLM devient utile lorsqu’une étape exige de structurer un texte, résumer plusieurs passages ou comparer des informations difficiles à exprimer par des conditions fixes. Il ne doit pas remplacer une règle déterministe claire.
Dans ce système, ils ne votent pas sur le même dossier. Chaque modèle remplit une fonction différente : analyse d’une source, OCR, structuration ou évaluation. Cette spécialisation peut rendre le pipeline plus pratique ; elle ne rend ni les sources indépendantes, ni la classification infaillible. La décision d’approfondir puis d’investir reste humaine.
La transformation technique et le déclenchement peuvent être automatisés lorsque le contenu possède un état d’approbation explicite, des contrôles et un retour arrière. L’angle, les preuves, les droits et la responsabilité éditoriale restent humains.
Elle permet d’interroger programmatiquement les données de performance selon des périodes, filtres et dimensions définis. Une chaîne peut ensuite historiser, comparer, visualiser et préparer un rapport. Les limites de couverture et l’état des données doivent rester visibles.
Choisissez un processus récurrent, borné, mesurable et réversible, avec une source fiable et un propriétaire. Si les règles ou responsabilités changent à chaque exécution, commencez par le processus, pas par l’IA.
Sources et limites
- Les quatre descriptions d’exploitation proviennent de la connaissance directe qu’IZZY a de ces projets, consignée le 25 août 2026 et complétée pour le workflow Search Console le 7 septembre 2026. Havana Club est nommé ; les autres clients et les détails susceptibles d’identifier les dispositifs sont volontairement omis.
- Aucun gain de temps, taux d’activation, qualité de décision, volume de publication, trafic, lead ou revenu n’est revendiqué : aucune base avant/après attribuable n’a été fournie. Les 15 à 25 minutes indiquées pour Search Console décrivent le temps de revue habituel, pas une économie mesurée.
- Google Search Console API et méthode Search Analytics : l’API expose des données de performance programmatiques, avec des limites de lignes et de fraîcheur à conserver dans l’interprétation.
- Les détails d’architecture, fournisseurs, modèles, critères, accès et politiques de conservation doivent être revérifiés pour chaque déploiement. Cet article n’est ni un audit technique, ni une évaluation de sécurité, de conformité ou de performance.