Glossaire
Les termes qui reviennent dans les articles de ce site, définis tels qu'ils sont utilisés ici : pas une encyclopédie générale de l'IA, mais le vocabulaire du corpus.
Où ces termes interviennent
Choisir une architecture
↓
Donner des capacités au système
↓
Faire fonctionner en production
Contraintes transversales
Un ordre de lecture, pas un ordre d'exécution : on arrive souvent par un workflow avant de reprendre l'architecture.
Choisir une architecture
Couche d'abstraction
L'interface entre les utilisateurs d'une entreprise et les modèles IA sous-jacents : ce qui gère l'authentification, le choix du modèle disponible, la mise à jour continue. Toute entreprise qui déploie de l'IA à l'échelle finit par en avoir une, que ce soit délibéré ou non. Un abonnement ChatGPT Business dans une PME en est déjà une, même si personne ne l'a formulé ainsi à la signature du contrat : la vraie question n'est pas si cette couche existe, mais qui la possède et qui la maintient.
→ L'architecture avant le modèle
Mono-provider
Architecture où l'entreprise délègue entièrement la couche d'abstraction au fournisseur du modèle (ChatGPT Enterprise, Copilot Microsoft 365, Gemini dans Google Workspace). Choix rationnel dans beaucoup de contextes de démarrage, avec des limites qui apparaissent typiquement après plusieurs mois de production.
→ L'architecture avant le modèle · Le mono-provider bundlé
Multi-provider
Architecture où l'entreprise construit ou fait construire sa propre couche d'abstraction pour arbitrer entre plusieurs modèles selon le cas d'usage, via un routeur comme OpenRouter ou une alternative auto-hébergée comme LiteLLM. Naît en général d'un besoin concret : des équipes différentes qui veulent des modèles différents, et un service juridique qui en interdit certains.
→ L'architecture avant le modèle · Le multi-provider SaaS · Acheter ou construire
LLM Gateway
Couche logicielle qui expose plusieurs modèles derrière une API unifiée : catalogue de modèles, routing, facturation consolidée, fallback automatique en cas d'indisponibilité d'un fournisseur. OpenRouter et LiteLLM en sont les exemples les plus utilisés au moment où j'écris ces lignes. Le rachat d'OpenRouter par Stripe, officialisé le 19 août 2026 pour un montant non divulgué que le New York Times situe autour de 7,5 milliards de dollars, donne la mesure de ce qu'est devenue cette couche : un actif stratégique disputé.
→ Et si Stripe rachetait OpenRouter ? · L'architecture avant le modèle
Coût total de possession (TCO)
Le premier axe d'évaluation d'une architecture IA, et il dépasse largement le prix affiché par utilisateur : licences, inférence facturée en tokens, maintenance de l'infrastructure, onboarding des équipes, compétences internes à recruter ou former. Chaque architecture répartit ces coûts différemment, certaines les concentrant dans une ligne budgétaire lisible, d'autres les éclatant entre postes IT et métier.
→ L'architecture avant le modèle · Acheter ou construire
Vendor lock-in
La dépendance à un fournisseur qui rend coûteux ou risqué le fait d'en changer, une fois l'infrastructure construite autour de ses spécificités. C'est précisément ce que des standards ouverts comme MCP permettent d'éviter : changer de modèle IA ne casse pas l'infrastructure d'intégrations bâtie autour.
Donner des capacités au système
Agent IA
Un système IA à qui l'on délègue non seulement une réponse, mais une capacité d'action : appeler des outils, accéder à des données, exécuter une tâche de bout en bout plutôt que produire un seul texte en sortie. C'est la couche qui rend MCP et les Skills nécessaires : sans eux, chaque agent réinvente sa propre façon de se connecter aux outils et de retenir une expertise métier.
MCP (Model Context Protocol)
Protocole ouvert publié par Anthropic fin 2024, né d'un besoin interne avant de devenir un standard : connecter les modèles de langage aux outils et aux données externes sans réécrire une intégration spécifique pour chaque plateforme IA. Un an après son lancement, l'alignement des acteurs majeurs et la gouvernance ouverte via la Linux Foundation en ont fait un standard de fait plutôt qu'une option parmi d'autres. Pour une entreprise, c'est ce qui évite le vendor lock-in : changer de modèle IA ne casse pas l'infrastructure d'intégrations construite autour.
Skill (agent IA)
Une expertise métier formalisée en instructions réutilisables par un agent IA, plutôt que réexpliquée à chaque session. Claude Skills en est l'implémentation la plus répandue. Le parallèle est direct avec les procédures opératoires standardisées (SOP) qu'une entreprise structurée écrit pour ses équipes humaines : mêmes bénéfices de cohérence, de scalabilité et de capitalisation du savoir-faire, appliqués cette fois à un agent plutôt qu'à un collaborateur.
→ Claude Agent Skills 1/2 · Claude Agent Skills 2/2
SOP (Standard Operating Procedure)
Procédure opératoire standardisée : la formalisation écrite d'une tâche, de ses critères de qualité et de ses cas particuliers, qu'une entreprise structurée produit pour ses équipes humaines. C'est le modèle sur lequel reposent directement les Skills : ce qu'une SOP fait pour un collaborateur, un Skill le fait pour un agent IA.
Orchestration
La couche logicielle qui donne à un agent ses outils, son accès réseau et sa boucle d'action autonome, par opposition au modèle lui-même qui ne fait que générer du texte. C'est aussi, à l'échelle d'une organisation, l'infrastructure sur laquelle des outils spécialisés se connectent plutôt qu'être reconstruits en interne un par un.
Prompt engineering
La pratique consistant à formuler et ajuster manuellement l'instruction donnée à un modèle pour obtenir le résultat voulu. Utile tant que chaque interaction repart de zéro. Dès qu'une tâche devient récurrente, formaliser cette expertise dans un Skill remplace le prompt engineering répété à chaque session par une procédure écrite une fois et réutilisée.
Faire fonctionner en production
n8n
Outil d'automatisation de workflows, positionné entre les solutions no-code grand public (Zapier, Make) et l'infrastructure d'orchestration IA en entreprise. La bascule d'un usage personnel à une plateforme d'équipe change ses contraintes réelles : sécurité des webhooks, sauvegarde des workflows, gestion des accès, et capacité à reconstruire l'instance quand tout casse.
→ n8n en production · Sécuriser et maintenir n8n
Workflow
Une séquence automatisée d'actions déclenchée par un événement (webhook, planification, action manuelle). Le piège classique : multiplier les workflows sans anticiper les dépendances qui se créent entre eux. Passé un certain nombre, ce ne sont plus les workflows pris individuellement qui posent problème, mais les dépendances invisibles qui les relient.
→ Pourquoi la plupart des projets d'automatisation échouent
Webhook
Un point d'entrée HTTP qui déclenche un workflow en réponse à un événement externe. Sa sécurisation repose sur la vérification de signature (HMAC), sans quoi n'importe qui connaissant l'URL peut déclencher le workflow à sa place.
Queue mode
Mode d'exécution de n8n où les workflows sont traités par des workers séparés via une file d'attente Redis, plutôt que dans le process unique du mode standard. Sa raison d'être première est l'isolation : chaque worker possède son propre event loop, sa propre mémoire et son propre domaine de crash, si bien qu'un workflow qui boucle ou qui sature la RAM n'emmène plus l'instance entière avec lui, éditeur compris. Le scaling horizontal en découle. La gestion d'erreurs change en revanche significativement, la reprise après crash d'un worker reposant sur un job lock dans Redis plutôt que sur le comportement d'une exécution standard qui échoue.
→ n8n en production · Sécuriser et maintenir n8n
Retry on Fail
Réglage disponible sur chaque node, qui relance automatiquement l'appel un nombre défini de fois avant de considérer l'étape en échec. Efficace contre les erreurs passagères : timeout, quota momentané, indisponibilité brève d'une API. Sur une opération non idempotente, il devient dangereux, puisque relancer une création d'enregistrement qui a déjà abouti produit un doublon au lieu d'une correction.
Continue on Error
Réglage qui laisse le workflow poursuivre son exécution malgré l'échec d'un node, en routant l'erreur vers une branche séparée au lieu d'interrompre tout le traitement. C'est ce qui permet de construire un équivalent local du try/catch : isoler l'item en échec, le consigner, laisser passer les autres.
Error Workflow
Workflow dédié que n8n déclenche automatiquement quand un autre workflow échoue, à condition de l'avoir désigné dans les réglages de ce dernier. Il reçoit le contexte de l'exécution fautive et sert de point unique de notification et de journalisation. Sans lui, un workflow qui tombe la nuit reste silencieux jusqu'à ce que quelqu'un finisse par remarquer que la donnée n'est jamais arrivée.
Idempotence
Propriété d'une opération qui produit le même résultat qu'elle soit exécutée une fois ou plusieurs fois. Dans un workflow n8n, l'absence d'idempotence est ce qui transforme un simple retry en incident : si le workflow a déjà envoyé un email ou créé un enregistrement avant de crasher, relancer le traitement produit des doublons plutôt que de corriger l'erreur.
Contraintes transversales
Guardrails
Les mécanismes qui encadrent ce qu'un système IA peut faire ou dire en production : filtrage de contenu, limites d'accès, blocage de requêtes jugées sensibles. Point de vigilance direct : ces mêmes guardrails, conçus pour bloquer un attaquant, ne savent généralement pas distinguer un attaquant d'un analyste de sécurité légitime qui étudie un incident.
→ Guardrails n8n · Incident Hugging Face
Gouvernance (IA)
L'ensemble des questions liées à qui a accès à quoi, comment le prouver en cas d'audit, et comment appliquer une politique d'usage cohérente sur des workflows automatisés qui manipulent des données sensibles. C'est l'axe le plus sous-estimé dans les déploiements IA en entreprise : les agents tournent déjà en production dans la plupart des organisations, bien avant que quiconque ait tranché qui peut les autoriser, les auditer ou les arrêter.
→ Guardrails n8n · L'architecture avant le modèle
Déterminisme
La propriété d'un système à produire la même sortie pour la même entrée. Les modèles de langage ne l'ont pas nativement, même configurés pour être aussi prévisibles que possible : des micro-variations subsistent, venant de l'infrastructure et de l'ordre de traitement. Pour un processus métier soumis à une obligation de non-discrimination ou au droit à l'explication du RGPD, cette absence de déterminisme n'est pas un détail technique mais un vrai risque de conformité.
RGPD / AI Act
Deux cadres réglementaires européens qui pèsent directement sur l'architecture IA d'une entreprise plutôt que sur le seul choix du modèle. Le RGPD impose un droit à l'explication qui entre en tension directe avec l'absence de déterminisme des LLMs. L'AI Act européen, en application progressive, pousse les organisations qui étaient enthousiastes sur l'IA il y a peu à documenter maintenant ce qu'elles ont déployé.
→ Guardrails n8n · Rendre l'IA déterministe
HMAC
Mécanisme de signature utilisé par les plateformes qui exposent des webhooks (Stripe, GitHub, Shopify inclus) pour garantir qu'une requête provient bien de la source attendue. Le principe : calculer un hash du corps de la requête avec une clé secrète partagée, et l'inclure dans un en-tête vérifié à la réception.
RBAC (contrôle d'accès basé sur les rôles)
Système qui détermine qui peut faire quoi sur une instance ou une plateforme, en fonction du rôle attribué plutôt que d'un accès individuel. Sur n8n, disponible à partir des plans Pro et Enterprise, et absent en Community au moment où je rédige cette note, ce qui devient un point de friction dès qu'une équipe grandit au-delà d'une poignée de personnes.