Workflows LLM ou agents : comment on choisit chez Lynakor

Le vrai problème : confondre automatisation et intelligence

Quand une ETI décide d'intégrer l'IA dans ses processus, elle se retrouve face à un choix qui n'en est pas vraiment un. D'un côté, les plateformes no-code promettent de tout automatiser en quelques clics. De l'autre, on lui parle d'agents autonomes capables de "réfléchir" et de s'adapter. Entre les deux, un flou artistique que beaucoup de prestataires entretiennent soigneusement.

Le résultat : des projets qui démarrent sur Make ou n8n, qui fonctionnent trois mois, puis qui s'effondrent dès que le besoin évolue. Ou des déploiements d'agents qui auraient dû être de simples workflows, avec une complexité injustifiée et des coûts qui explosent.

Chez Lynakor, on refuse ce flou. On distingue trois approches, chacune avec ses cas d'usage légitimes.

Les workflows visuels : quand la simplicité suffit

n8n, Make, Zapier — ces outils ont leur place. Pour connecter deux applications, déclencher une action sur un événement, formater des données entre systèmes, ils font le travail. Un commercial qui veut automatiser l'envoi d'un email de bienvenue après une inscription ? Parfait. Un DAF qui synchronise ses factures entre deux logiciels ? Idéal.

Les limites apparaissent vite :

• Vendor lock-in — votre logique métier est prisonnière d'une interface propriétaire
• Tests impossibles — pas de versioning, pas de revue de code, pas de CI/CD
• Maintenance opaque — quand ça casse, bonne chance pour comprendre où
• Scalabilité limitée — dès que la logique se complexifie, les canvas deviennent illisibles

Pour des tâches simples et stables, ces outils restent pertinents. Mais dès qu'on intègre des LLM, les choses changent.

Les scripts LLM : lisibles, testables, maîtrisés

Un pipeline LLM, c'est une séquence d'appels à des modèles de langage, avec de la logique métier entre chaque étape. Extraire des informations d'un document, les enrichir, les classifier, générer une réponse structurée. Du code, pas de la magie.

Pourquoi privilégier les scripts plutôt que les workflows visuels pour ces pipelines ?

• Lisibilité — un développeur comprend en quelques minutes ce que fait le système
• Testabilité — on écrit des tests unitaires, on versionne, on déploie proprement
• Pas de dépendance — si le prestataire change de tarif ou disparaît, le code reste
• Performance — on optimise où c'est nécessaire, pas où l'outil le permet

Chez Lynakor, c'est notre choix pour tout ce qui ressemble à un workflow LLM déterministe. Une chaîne de traitement documentaire, une génération de rapports, une extraction structurée — ça se code, ça se teste, ça se maintient.

Les agents : quand l'autonomie est réellement nécessaire

Le mot "agent" est devenu un fourre-tout marketing. On l'utilise pour désigner n'importe quel script qui appelle GPT. C'est un problème, parce que les vrais systèmes agentiques répondent à des besoins très différents.

Un agent, au sens technique, c'est un système capable de :

• Planifier — décomposer un objectif en sous-tâches sans qu'on lui dicte le chemin
• Itérer — évaluer ses résultats et ajuster son approche
• Mémoriser — conserver le contexte sur la durée, apprendre de ses interactions
• Utiliser des outils — décider quand et comment mobiliser des capacités externes

Nous avons détaillé ces caractéristiques dans notre article sur les 6 piliers d'un système agentique. La distinction est fondamentale : un workflow exécute une séquence prédéfinie, un agent navigue vers un objectif.

Quand utiliser un agent plutôt qu'un workflow ? Quand la situation l'exige vraiment :

• L'espace des solutions est trop vaste pour être pré-cartographié
• Les conditions changent entre le début et la fin de la tâche
• L'humain ne peut pas (ou ne veut pas) micro-manager chaque étape

Le choix de Lynakor : scripts + Hermes

Notre approche est pragmatique. Pour les pipelines LLM déterministes — extraction, génération, classification — on code. Des scripts Python, versionnés, testés, déployables n'importe où. Pas de dépendance à une plateforme, pas de canvas qui devient ingérable.

Pour les cas réellement agentiques, on a développé Hermes, notre runtime agentique. Un environnement d'exécution souverain, hébergé en France, qui permet à des agents de fonctionner avec les 6 piliers nécessaires : identité persistante, mémoire structurée, capacité d'introspection, outils modulaires, orchestration multi-agents, et gouvernance explicite.

Clara, notre Directrice Marketing IA, illustre cette approche. Elle ne se contente pas d'exécuter des tâches qu'on lui assigne. Elle planifie sa stratégie éditoriale, adapte ses contenus selon les retours, maintient une cohérence sur la durée. C'est un agent, pas un workflow déguisé.

Comment décider pour votre cas

Posez-vous trois questions :

Le processus est-il stable et prévisible ? Si oui, un workflow visuel ou un script suffit. Ne sur-ingénieriez pas.

Y a-t-il des appels LLM avec une logique métier complexe ? Passez aux scripts. Vous gagnerez en maintenabilité et en contrôle.

L'objectif nécessite-t-il une adaptation en temps réel, une mémoire persistante, une planification autonome ? Là, et seulement là, un agent se justifie.

La plupart des projets qu'on nous présente comme "agentiques" sont en réalité des workflows LLM qui méritent d'être codés proprement. Et c'est très bien. L'agent n'est pas une fin en soi, c'est une réponse à un type de problème spécifique.