Publications

Construire des agents IA dans n8n, c'est devenu mon quotidien. Mais le vrai défi, ce n'est jamais le prototype — c'est la mémoire en production.

Sur un projet récent d'agent de support client, j'ai dû gérer trois types de mémoire distincts : la mémoire de session pour le contexte immédiat, une mémoire sémantique via RAG pour retrouver les bonnes infos produit, et une mémoire procédurale pour les workflows récurrents.

Le piège classique : tout mettre dans le contexte de la conversation. Résultat — des tokens qui explosent, des latences qui grimpent, et un agent qui devient incohérent au bout de quelques échanges.

La bonne architecture, c'est de traiter chaque type de mémoire séparément et de ne charger que ce dont l'agent a besoin au bon moment. Dans n8n, ça se traduit par des nodes de retrieval conditionnels et une gestion fine du prompt final.

La complexité d'un agent IA ne se voit pas dans la démo — elle se révèle à 3h du matin quand la prod décroche.

#n8n #AIAgents #LLM #Automatisation

ChatGPT Pulse travaille pendant que tu dors. Moi, j'ai n8n pour ça depuis des mois.

La nouvelle fonctionnalité d'OpenAI fait du bruit : un assistant proactif qui agit sans qu'on lui demande, en arrière-plan, de façon autonome.

Honnêtement ? C'est exactement ce que je construis avec n8n depuis longtemps.

Des workflows qui tournent la nuit, collectent des données, envoient des rapports, déclenchent des actions — sans intervention humaine. La différence, c'est que ma version est personnalisée à 100%, connectée à mes propres outils, et je garde la main sur chaque étape.

Ce que Pulse va démocratiser côté grand public, l'automatisation sur mesure le fait déjà côté entreprise. Et l'arrivée de ces fonctionnalités natives dans ChatGPT va surtout accélérer la demande pour des architectures plus complexes, plus contrôlées, plus fiables.

Les entreprises vont vouloir aller plus loin que ce que propose un outil grand public. C'est là que les experts en automatisation deviennent indispensables.

#n8n #IA

Codex prend de l'ampleur, et mon stack change en temps réel.

Depuis quelques semaines, j'intègre Codex dans mes workflows n8n pour automatiser des tâches qui me prenaient des heures : génération de scripts de traitement de données, debug automatique de nœuds qui plantent, documentation de mes automatisations à la volée.

Le vrai game changer ? Coupler Codex avec un agent n8n qui surveille mes repos GitHub. Dès qu'un workflow casse en prod, l'agent analyse l'erreur, interroge Codex, et propose un correctif directement dans Slack. Zéro intervention manuelle pour 80% des bugs courants.

Ce que j'observe concrètement : le temps passé à débugger a chuté de moitié. Ce que je gagne en temps, je le réinvestis dans des automatisations plus complexes, plus rentables.

On n'est plus dans l'ère "l'IA m'aide à coder". On est dans l'ère "l'IA gère l'infrastructure pendant que je conçois la stratégie".

Le métier d'automatiseur évolue vite — ceux qui s'adaptent maintenant prennent une longueur d'avance décisive.

#n8n #automation

En train de tester le MCP Server de n8n et honnêtement, ça change tout.

Tu décris en langage naturel le workflow que tu veux — directement dans Claude ou ChatGPT — et n8n le construit pour toi en quelques minutes. Pas de copier-coller, pas d'aller-retour, pas de friction.

Concrètement, sur un projet d'automatisation RH la semaine dernière, j'ai généré une base de workflow en 3 minutes chrono. Ce qui m'aurait pris 30-40 minutes à construire from scratch.

Ce qui est sous-estimé ici : ce n'est pas juste un gain de temps. C'est une nouvelle façon d'itérer. Tu testes une idée d'automatisation en quelques minutes, tu valides le concept, tu affines. Le cycle prototype → test devient quasi instantané.

La vraie barrière à l'automatisation n'a jamais été technique — c'était la friction du démarrage. Avec ce genre d'outil, cette excuse disparaît définitivement.

#n8n #automatisation

La recherche d'emploi en 2026 c'est un job à plein temps. Scraper les offres, les trier, adapter son CV, rédiger une lettre de motivation — multiplié par 10 candidatures par semaine, on est à 5-6 heures de travail mécanique.

J'ai décidé d'automatiser tout ça.

Ce que le système fait automatiquement :

Chaque matin, des workflows n8n scrappent LinkedIn et Indeed selon mes critères (titre, localisation, salaire). Claude analyse chaque offre et lui attribue un score de pertinence de 1 à 10. Les offres pertinentes déclenchent automatiquement la génération d'un CV adapté aux mots-clés ATS de l'offre, puis d'une lettre de motivation personnalisée. Une notification Telegram me résume les meilleures opportunités du jour.

Ce que j'ai appris en le construisant :

Le plus dur n'était pas l'automatisation elle-même — c'était le prompt engineering pour que Claude évalue correctement la pertinence sans sur-filtrer ni sous-filtrer. J'ai dû itérer une dizaine de fois sur le scoring.

Le deuxième défi : la déduplication. Sans elle, les mêmes offres reviennent chaque jour. J'ai résolu ça avec un hash des offres stocké dans Google Sheets.

Résultat : 4h récupérées par semaine, 3x plus de candidatures envoyées, zéro copier-coller.

Le système est open-source — les workflows sont disponibles dans ma bibliothèque.

En construisant mon système Job Seeking Automation, j'ai passé 2 jours sur un bug silencieux qui ne générait aucune erreur — la chaîne s'arrêtait simplement en milieu de traitement.

Le problème : SplitInBatches v3 avec batchSize=1 et N items. Si le sous-workflow appelé retourne 0 items (offre non pertinente, filtrée), la boucle se coupe net. Résultat : sur 10 offres à traiter, seules 4 passaient — sans le moindre message d'erreur.

La cause : SplitInBatches maintient un state interne. Quand le retour est vide, il considère que la boucle est terminée et envoie les items sur l'output "done" immédiatement.

La solution — Index Loop Pattern :

Au lieu de SplitInBatches, utiliser un compteur en staticData :

1. Node "Get Next Item" lit l'index courant depuis staticData
2. IF done? vérifie si index >= total
3. Set Item Data prépare les données de l'item courant
4. Execute Sub-Workflow avec alwaysOutputData: true + onError: continueRegularOutput
5. Combo Done retourne toujours 1 item (runOnceForAllItems)
6. Advance Index incrémente et reboucle vers Get Next Item

Ce pattern garantit que la boucle continue même si le sous-workflow retourne 0 items.

À retenir : SplitInBatches v3 est interdit avec des sous-workflows qui peuvent retourner 0 items. Toujours utiliser l'Index Loop Pattern dans ce cas.

Google vient de sortir deux outils qui changent radicalement le workflow de développement web : Stitch pour le design-to-code, et Antigravity pour le déploiement. J'ai testé le combo sur un cas concret.

Le test : recréer une page de pricing inspirée de Stripe, de zéro, sans toucher à Figma ni à un éditeur de code.

Stitch prend un screenshot ou une description et génère le HTML/CSS correspondant. La qualité est surprenante — les composants sont propres, le responsive fonctionne, et on peut itérer en langage naturel ("rends le bouton plus grand", "ajoute une ombre sur la card").

Antigravity prend le output de Stitch et le déploie en quelques secondes sur une URL publique. Pas de configuration, pas de CI/CD, pas de DNS à gérer.

Résultat en 45 minutes : une page pricing fonctionnelle, responsive, déployée en prod. Ce qui aurait pris une demi-journée avec le stack classique.

Les limites : pour des projets complexes avec logique métier, état dynamique ou intégrations API, on atteint vite les limites. C'est un outil de prototypage rapide et de landing pages, pas un remplaçant de Next.js.

Pour qui ? Parfait pour les indépendants qui veulent un site vitrine propre sans investir 2 jours de dev. J'utilise d'ailleurs ce stack comme point de départ pour mes projets clients.