Le stack d'IA agentique

Délimitation

Cet article traite des stacks d'IA agentique, principalement pour les workflows d'entreprise.

Il ne s'agit pas de tous les autres types d'IA et il ne s'agit pas non plus des agents de codage.

L'IA est un domaine immense, je me concentre ici uniquement sur les agents d'IA qui peuvent être utilisés pour les workflows d'entreprise.

Terminologie

C'est parti :

Le stack d'IA agentique est une décision stratégique

Je suis de ceux qui aiment exploiter le plein potentiel de l'IA. Lorsque j'ai envisagé de construire un stack d'IA agentique pour mon activité de conseil, il était clair pour moi que je voulais le posséder, pas le louer. C'est comme une maison, je veux un actif commercial. C'est ainsi que je suis arrivé à l'open source. Mais je ne suis pas un dogmatique. Et je ne suis pas non plus une grande entreprise.

Ma motivation pour écrire cet article était de comprendre les différents types de stacks d'IA agentique qui existent.

Tout ne convient pas à tout le monde

Avant de choisir un stack d'IA agentique, il faut rechercher quels types sont adaptés à son propre secteur, à la taille de son organisation, à son type d'organisation, à sa stratégie, à ses collaborateurs et partenaires, etc.

Avoir son propre stack d'IA agentique n'est pas non plus rentable pour tous les domaines d'activité. Il y a des domaines qui sont si standardisés partout qu'on peut simplement acheter des solutions prêtes à l'emploi sur le marché et les intégrer.

Dans certains secteurs, cependant, il n'y a pas le choix, en raison de la réglementation, de données très sensibles ou de secrets commerciaux.

Il faut donc se pencher sérieusement sur la question de savoir quel stack d'IA est envisageable pour soi. Selon le secteur ou la taille de l'entreprise, on optera pour un stack d'IA différent. Les coûts et la rapidité avec laquelle on souhaite voir des résultats entrent bien sûr aussi en ligne de compte dans la décision.

Dans les très grands groupes, il peut même arriver que différents départements aient des stacks d'IA agentique différents, car les exigences varient.

Liberté vs. Discipline

En faisant mes recherches, j'ai pris conscience que dans certains cas, on se situe également dans le champ de tension liberté vs. discipline. Plus je veux de liberté, plus je dois être discipliné dans le développement et la gouvernance.

C'est donc un compromis.

Le stack d'IA agentique détermine le modèle opérationnel

Après avoir lu cet article, vous comprendrez assez vite que le stack d'IA est déterminant pour le modèle opérationnel, la forme de l'organisation et les méthodes de travail. Ce que cela signifie en détail dans chaque cas, j'y reviendrai dans des articles ultérieurs. Aujourd'hui, il s'agit de vous donner une vue d'ensemble, et vous verrez très vite où se situent les différences.

Pas de recommandations de vendors

J'ai délibérément omis les noms des fournisseurs et des solutions existants. Vous devez faire vos propres recherches. Je ne travaille pour aucun fournisseur et n'ai aucune préférence.

Je n'ai également écrit aucune recommandation intentionnellement. Cela dépend vraiment de tant de facteurs. Tout ne peut pas tenir dans un seul article, cela ne peut être découvert qu'à travers plusieurs entretiens personnels.

Des erreurs peuvent se produire

Des erreurs ont pu se glisser et je serais ravie que vous me les signaliez. Aidez-moi à améliorer cet article. Merci beaucoup !

Les 6 couches d'architecture d'un stack d'IA agentique

Chaque couche s'appuie sur la précédente. Sans une compréhension des couches inférieures, les décisions prises dans les couches supérieures ne sont pas fondées.

1

Infrastructure

Définition et objectif : La couche d'infrastructure est la base physique ou virtuelle sur laquelle opèrent toutes les autres couches. Elle répond à la question : « Où tournent les GPU qui calculent les modèles ? »

L'infrastructure fournit la puissance de calcul, le stockage et la connectivité réseau. C'est la fondation.

Ce qui existe :

• Cloud — Hyperscalers (US) : Cloud full-stack avec instances GPU, disponible mondialement
• Cloud — Hyperscalers (UE) : Régions UE disponibles
• Cloud souveraine : Données en UE, conforme au RGPD
• Spécialistes GPU : Infrastructure optimisée pour les GPU, souvent moins chère
• GPU Serverless : Paiement à l'usage, pas de gestion d'infrastructure
• Matériel local : Propres serveurs en centre de données
• Propre matériel local sans serveur

Important :

L'infrastructure détermine la localisation des données (sur site vs. cloud), la scalabilité (cloud bursting) et la conformité (RGPD, BaFin, souveraineté). Une mauvaise décision d'infrastructure est coûteuse à corriger par la suite.

2

Model Serving — comment les modèles sont hébergés

Définition et objectif : Le model serving est la couche logicielle qui charge, gère les modèles d'IA et traite les requêtes d'inférence. C'est le « cerveau » de l'IA — sans model serving, il n'y a pas d'intelligence.

Le model serving fournit les modèles en tant que service — avec des API qui peuvent être appelées par les agents. Il gère les versions des modèles, la taille des lots (batch) et l'optimisation des performances.

Ce qui existe :

Propriétaire

• API : Modèles Frontier — meilleures performances, pas d'infrastructure propre
• API d'entreprise : Fonctionnalités d'entreprise, certifications de conformité
• Serving d'entreprise auto-hébergé : Haute performance, support d'entreprise

Open Source / Open-Weight

• API (hébergée) : Modèles Open-Weight — modèles ouverts, hébergement chez le fournisseur
• Marketplaces de modèles : nombreux modèles, paiement à l'usage
• Inférence auto-hébergée : contrôle total, infrastructure propre

Important :

Le model serving détermine quelle intelligence est disponible, la rapidité des réponses et où les données sont traitées. Le Task-Model-Matching signifie que chaque tâche n'a pas besoin du modèle le plus grand et le plus cher. On attribue à chaque tâche le modèle approprié. Cela réduit les coûts et améliore les performances. La condition préalable est de comprendre quel type de modèle est nécessaire pour quelle tâche.

3

Agent Runtime

Définition et objectif : L'agent runtime est l'environnement d'exécution pour les agents d'IA. Il peut comprendre les éléments suivants, sachant que tous les runtimes d'agents existants ne couvrent pas toutes ces fonctionnalités :

• Gestion des processus : Démarrer, arrêter, exploiter les agents de manière persistante. Cycle de vie de l'initialisation à la fin.
• Gestion de l'état (State Management) : Maintenir l'état d'un agent en cours d'exécution de manière persistante au-delà des sessions. Checkpointing en cas d'interruption.
• Exécution durable : Enregistrer chaque étape d'exécution de manière persistante. En cas d'arrêt, d'erreur ou d'interruption, reprendre exactement là où l'agent s'était arrêté.
• Gestion du contexte : Contrôle ce qui entre dans la fenêtre de contexte du modèle. Historique de la conversation, contexte pertinent, résumés.
• Sandboxing : Environnement d'exécution isolé par agent. Exécution de code, accès aux fichiers et commandes sans risque pour les systèmes de production.
• Intégration d'outils : Enregistrer des systèmes externes en tant que fonctions appelables. API, bases de données, systèmes de fichiers, navigateurs, serveurs MCP. Gestion des identifiants (Credential Management) et permissions délimitées (Scoped Permissions) par agent.
• Système de compétences (Skill System) : Enregistrer des modèles de solution réutilisables issus de tâches passées, les rendre consultables et les appliquer à de nouvelles tâches. L'agent apprend de son propre travail.
• Coordination multi-agents : Délégation, parallélisation, communication entre agents, listes de tâches partagées. Sous-agents pour les sous-tâches séquentielles, équipes d'agents pour les flux de travail parallèles.
• Auto-évaluation : L'agent définit des critères de succès, évalue ses propres résultats, itère jusqu'à ce que les critères soient remplis.
• Routage des messages : Communication avec les utilisateurs et les systèmes externes via différents canaux.
• Planification (Scheduling) : Exécution programmée, basée sur des événements ou déclenchée par d'autres agents.
• Routage de modèles : Contrôle quel modèle est utilisé pour quel agent ou quelle tâche.
• Observabilité : Traçage, débogage, piste d'audit pour toutes les actions de l'agent.

Ce qui existe :

Propriétaire

• Plateformes managées : entièrement gérées, fonctionnalités d'entreprise
• Natives du cloud : Intégration dans l'écosystème cloud
• RPA+IA d'entreprise : infrastructure RPA existante

Open Source / Hybride

• Frameworks : contrôle total, auto-hébergé
• Low-code : création visuelle de workflows
• Agents personnels : installation locale, intégration IDE

Important :

L'agent runtime détermine comment les workflows sont construits, orchestrés et connectés aux outils. C'est la couche avec le plus grand risque de dépendance (lock-in), car toute la logique de déroulement s'y trouve. Un changement de runtime signifie généralement devoir reconstruire les workflows. La portabilité est également limitée entre les frameworks open source.

4

Données & Connaissances

Définition et objectif : La couche de données et de connaissances fournit un stockage persistant pour les données et le savoir. C'est la « mémoire » du système. Sans elle, les agents oublient tout après chaque session.

Cette couche peut contenir :

• Mémoire (multi-niveaux) : La mémoire à court terme conserve le contexte au sein d'une tâche en cours. La mémoire à long terme stocke les connaissances sur les utilisateurs, les projets et les interactions passées au-delà des sessions. La mémoire procédurale stocke des modèles de solution réutilisables.
• Récupération (RAG) : Les agents recherchent les connaissances pertinentes avant de répondre. La tendance s'éloigne de la simple recherche vectorielle pour aller vers la récupération hybride, qui combine la recherche sémantique avec des requêtes structurées.
• Graphes de connaissances (Knowledge Graphs) : Modélisent les relations entre les entités (personnes, processus, systèmes, documents). Permettent un raisonnement multi-sauts (multi-hop reasoning). Le RAG standard seul n'y parvient pas.
• Ingestion de données : Analyser (parser), segmenter (chunker), extraire les métadonnées, encapsuler (embedder), indexer les documents. Sans pipeline d'ingestion, la couche de connaissances est vide. La qualité de l'ingestion détermine la qualité de toutes les réponses.
• Actualité des données : Les connaissances deviennent obsolètes. Les pipelines d'ingestion doivent fonctionner en continu, pas une seule fois. Des connaissances obsolètes ou contradictoires dans le système sont pires que l'absence de connaissances.

Ce qui existe :

Les technologies suivantes constituent la mémoire propre du système d'agents. De plus, les agents d'IA peuvent accéder à n'importe quelle source de données via l'intégration d'outils (ce qui relèverait de la couche 3). Dans la couche 4, on trouve :

• Bases de données vectorielles (embeddings pour la recherche sémantique et le RAG)
• Graphes de connaissances (relations entre entités, raisonnement multi-sauts)
• Bases de données de documents (documents non structurés, recherche plein texte)
• Bases de données en mémoire (état de session, mémoire à court terme, caches)
• Connaissances personnelles (wikis, systèmes de prise de notes, collections Markdown)

Important :

La couche de données et de connaissances détermine ce que les agents d'IA savent. La qualité de cette couche limite la qualité de toutes les réponses de l'agent — peu importe la qualité du modèle ou de la runtime. De mauvaises données dans une bonne runtime avec un bon modèle produisent de mauvais résultats. Sans cette couche, les agents d'IA repartent de zéro à chaque requête.

La différence entre cette couche et les requêtes de base de données via des appels d'outils de la couche 3 mériterait un article à part entière.

5

Gouvernance & Contrôle

Définition et objectif : La couche de gouvernance et de contrôle applique les règles, les politiques et les exigences de conformité. Elle garantit que les agents d'IA opèrent dans des limites définies.

Elle contient :

• Application des politiques (Policy Enforcement) : Règles lisibles par machine (par ex. pas de données PII sans masquage, pas d'actions au-delà de certains seuils sans validation)
• Contrôle d'accès : Qui peut utiliser quels agents d'IA, voir quelles données, exécuter quelles actions (RBAC, ABAC)
• Classification des données : Quelles données peuvent entrer dans les contextes des agents, lesquelles ne le peuvent pas. Étiquettes de sensibilité.
• Garde-fous d'entrée/sortie (Guardrails) : Protection contre l'injection de prompt, détection d'hallucination, filtres de contenu.
• Journalisation d'audit : Journalisation complète de toutes les actions de l'agent (qui, quand, quoi, avec quel résultat)
• Rapports de conformité : Rapports pour les autorités et les parties prenantes internes (BaFin, RGPD, EU AI Act, réglementations sectorielles)

Ce qui existe :

• Moteurs de politiques (règles déclaratives lisibles par machine sous forme de code)
• Gestion des identités et des accès (SSO, RBAC, OAuth2, OIDC, cycle de vie utilisateur)
• Journalisation & Surveillance (logs, métriques, alertes, tableaux de bord)
• Observabilité de l'IA (traçage spécifique à l'agent, suivi des tokens, latence, coût par appel d'agent)
• Plateformes de conformité (RGPD, SOC2, ISO, EU AI Act, spécifiques au secteur)
• Gouvernance native du cloud (application des politiques intégrée à l'infrastructure cloud)
• Sécurité de l'IA & Garde-fous
• Classification des données & DLP
• Gouvernance des modèles (versionnage de modèles, registre, workflows d'approbation)
• Piste d'audit & analyse forensique
• Gouvernance des coûts (budgets de tokens par agent, équipe, cas d'usage, alertes en cas de dépassement de seuils)

Important :

La gouvernance est la différence entre la démo et la production. Sans gouvernance, pas de conformité, pas d'audit, pas de confiance. La question est de savoir si on la construit soi-même ou si on l'obtient du vendor.

6

Interface

Définition et objectif : La couche d'interface est le point d'accès pour les utilisateurs et les systèmes externes. C'est le « visage » du système, l'interface à travers laquelle les humains et d'autres systèmes interagissent avec les agents.

Une interface permet :

• Interaction utilisateur : Chat, portail, application mobile
• Intégration système : API pour d'autres applications
• Multi-canal : Slack, Teams, WhatsApp, Web, Mobile
• Personnalisation : Expériences spécifiques à l'utilisateur

Ce qui existe :

• Plateformes de messagerie (intégration de chat d'entreprise/communautaire)
• Messagerie d'entreprise (mobile-first, grande portée)
• Frameworks web (applications web personnalisées)
• Portails low-code (développement rapide de portails)
• Passerelles API (gestion d'API, limitation de débit)
• Plateformes de chatbot (création visuelle de bots)
• Interfaces vocales (commande vocale)
• Intégration IDE (focus sur les développeurs)

Important :

L'interface détermine l'acceptation par les utilisateurs. Le meilleur système d'agents d'IA ne sert à rien si les utilisateurs ne peuvent pas ou ne veulent pas l'utiliser.

Résultat intermédiaire

Les différentes couches sont une façon abstraite de voir les choses, qui aide à décomposer « le grand sujet inconnu » en unités compréhensibles.

Même si vous n'êtes pas un technicien, vous pouvez vous faire une idée approximative de chaque couche.

Cette abstraction aide énormément à comprendre les différents types de stacks d'IA agentique.

Voici ceux que j'ai identifiés. Il peut y avoir d'autres types. Je me suis limité aux plus courants.

Différents types de stacks d'IA agentique

Chaque organisation ne doit pas nécessairement construire les 6 couches elle-même. Les plateformes couvrent différentes couches. Chaque type est présenté avec un diagramme complet à 6 couches.

Il existe les types suivants :

1. Intégrés à un écosystème (Ecosystem-Integrated)
2. Plan de contrôle managé (Managed Control Plane)
3. Suites applicatives d'entreprise (Enterprise Application Suites)
4. Infrastructure uniquement (Infrastructure-Only)
5. Exécution managée & contrôle auto-hébergé (Managed Execution & self-hosted Control)
6. Fait maison / Frameworks open source

Il existe aussi des formes mixtes, mais l'article est déjà très long, donc je ne considérerai que celles-ci.

Pour chaque type, nous examinerons les couches d'architecture.

Légende des couleurs :

Type 1 : Plateformes intégrées à un écosystème

L'IA en tant que fonctionnalité dans l'écosystème existant. Profondément intégrée, mais utilisable uniquement au sein de l'écosystème.

Ce type décrit des plateformes qui mettent l'IA à la disposition de tous les employés. Le type 3 serait plutôt destiné à des domaines d'activité spécifiques. Certains fournisseurs sont parfois les deux.

La gouvernance en détail

Le vendor prend en charge : DLP complète, centre de conformité avec des modèles, journaux d'audit au format de l'écosystème (pour l'eDiscovery), classification automatique des données, intégration dans les applications de l'écosystème, protection contre l'injection de prompt, validation de base des sorties.

L'organisation doit faire elle-même : Configurer les politiques spécifiques à l'écosystème, gérer les utilisateurs dans l'écosystème, le reporting n'est possible que dans le cadre de l'écosystème, attribuer des étiquettes de sensibilité aux documents. Les agents externes ne sont pas couverts.

Adaptabilité des workflows & liberté des cas d'usage

• Conception des workflows : Paradigme de l'écosystème (par ex. Copilot Studio : Power-Fx, Google : AppScript)
• Sélection des cas d'usage : Uniquement les cas d'usage au sein de l'écosystème (Teams, Outlook, Gmail, Docs)
• Intégrations : Uniquement les applications de l'écosystème + connecteurs externes limités
• Logique métier : Uniquement si l'écosystème la prend en charge
• Scalabilité : L'écosystème évolue automatiquement, mais les coûts de licence augmentent de manière linéaire
• Transformation de l'entreprise : Uniquement l'optimisation des processus existants de l'écosystème, pas de nouveaux modèles économiques

Type 2 : Plateformes avec plan de contrôle managé

Plateformes entièrement managées qui fournissent les couches 1, 3, 4, 5, 6. L'organisation ne décide que de la couche 2 (sélection du modèle) et définit ses propres workflows.

La gouvernance en détail

Le vendor prend en charge : Intégration RBAC/SSO, infrastructure de journalisation d'audit, politiques de base (limites de débit, quotas), certification de conformité de la plateforme (SOC2, ISO27001), tableau de bord de surveillance, protection contre l'injection de prompt, validation de base des sorties.

L'organisation doit faire elle-même : Définir ses propres politiques métier, configurer les rôles des utilisateurs, créer des rapports de conformité pour les autorités (BaFin, RGPD), concevoir des workflows avec intervention humaine (human-in-the-loop), définir des politiques de classification des données.

Adaptabilité des workflows & liberté des cas d'usage

• Conception des workflows : Les workflows doivent suivre le paradigme de la plateforme
• Sélection des cas d'usage : Tous les cas d'usage sont possibles, tant que les modèles de la plateforme les prennent en charge
• Intégrations : Les connecteurs de la plateforme sont disponibles, les intégrations personnalisées nécessitent du code spécifique à la plateforme
• Logique métier : Une logique personnalisée complexe n'est possible que si la plateforme la prend en charge
• Scalabilité : La plateforme évolue automatiquement, le contrôle des coûts est de votre propre responsabilité
• Transformation de l'entreprise : Tester rapidement de nouveaux cas d'usage, mais risque de dépendance en cas de succès

Type 3 : Suites applicatives d'entreprise

Packages complets de fournisseurs d'entreprise. Combinez l'infrastructure jusqu'à l'interface dans une seule suite.

La gouvernance en détail

Le vendor prend en charge : Gouvernance interne complète de la suite, intégration dans les applications de la suite, conformité pour les cas d'usage de la suite (certifiée), journaux d'audit pour les actions de la suite, gouvernance des données au sein de la suite, protection contre l'injection de prompt, validation de base des sorties.

L'organisation doit faire elle-même : Configurer les politiques de la suite, gérer les utilisateurs dans la suite, gouvernance uniquement au sein de la suite (les agents externes ne sont pas couverts), reporting uniquement pour les cas d'usage de la suite, construire soi-même les scénarios hybrides.

Adaptabilité des workflows & liberté des cas d'usage

• Conception des workflows : Paradigme de la suite
• Sélection des cas d'usage : Uniquement les cas d'usage que la suite prend en charge
• Intégrations : Intégration profonde avec la suite, systèmes externes uniquement via les connecteurs de la suite
• Logique métier : Uniquement si la suite la prend en charge
• Scalabilité : La suite évolue automatiquement, mais les coûts de licence augmentent fortement
• Transformation de l'entreprise : Uniquement une transformation dans le cadre de la suite, pas de produits natifs IA en dehors

Type 4 : Fournisseurs d'infrastructure uniquement

Uniquement l'infrastructure et le model serving (couches 1–2). L'organisation construit elle-même les couches 3–6.

La gouvernance en détail

Le vendor prend en charge : Uniquement la sécurité de l'infrastructure (sécurité physique, isolation réseau). Aucune fonctionnalité de gouvernance, pas de journalisation d'audit, pas d'outils de conformité, pas de protection des prompts, pas de validation des sorties, pas d'intervention humaine.

L'organisation doit faire elle-même : Construire l'intégralité du stack de gouvernance, mettre en œuvre des garde-fous spécifiques aux modèles (par ex. pas de PII dans les requêtes de modèle), journalisation d'audit interne (tous les appels de modèle avec ID utilisateur, horodatage, hachage entrée/sortie), rapports de conformité internes, protection contre l'injection de prompt interne, validation des sorties interne, workflows d'escalade internes.

Adaptabilité des workflows & liberté des cas d'usage

• Conception des workflows : N'importe quel paradigme, code personnalisé
• Sélection des cas d'usage : N'importe quel cas d'usage possible, les API de modèle sont génériques
• Intégrations : Chaque intégration est faite en interne, pas de limites de connecteurs de vendor
• Logique métier : Sans limites, code personnalisé entre l'utilisateur et le modèle
• Scalabilité : Le fournisseur fait évoluer l'infrastructure, le contrôle des coûts est de votre responsabilité
• Transformation de l'entreprise : Modèles économiques entièrement nouveaux, les API de modèle sont une commodité

Type 5 : Exécution managée & contrôle auto-hébergé

Le fournisseur de modèle fournit l'inférence et une exécution capable d'utiliser des outils via une API. L'organisation construit toute la logique de l'agent par-dessus : mémoire, compétences, orchestration, planification, coordination multi-agents.

L'infrastructure (couche 1) et le model serving (couche 2) sont chez le fournisseur. La couche 3 est partagée : l'exécution est chez le fournisseur, tout ce qui est au-dessus est chez l'entreprise. L'organisation construit elle-même les couches 4, 5 et 6.

La gouvernance en détail

Le vendor prend en charge : Garde-fous de sécurité propres au modèle (filtres de contenu, intégrés au modèle), limitation de débit au niveau de l'API et suivi de l'utilisation, données de consommation de tokens via le tableau de bord de l'API.

L'organisation doit faire elle-même : Politiques OPA/Kyverno, Keycloak/Auth0, validation des sorties (détection d'hallucination, filtres de contenu, vérifications de schéma JSON), ELK/Grafana, journalisation d'audit, rapports de conformité (BaFin-MaRisk, RGPD, GxP), workflows d'escalade, protection contre l'injection de prompt.

Adaptabilité des workflows & liberté des cas d'usage

• Conception des workflows : N'importe quel paradigme pour l'orchestration construite en interne, mais les modèles d'exécution sont dictés par le vendor
• Sélection des cas d'usage : N'importe quel cas d'usage possible, tant qu'il peut être représenté via l'API du fournisseur
• Intégrations : Chaque intégration est construite en interne
• Logique métier : Sans limites de plateforme dans le code personnalisé, les capacités d'exécution dépendent du fournisseur d'API
• Scalabilité : Faire évoluer soi-même ses propres couches, le fournisseur fait évoluer l'inférence, la responsabilité des coûts de tokens vous incombe
• Transformation de l'entreprise : Nouveaux modèles économiques possibles, avec une dépendance au niveau de la couche d'exécution. La différenciation réside dans l'orchestration construite en interne et dans la connaissance du domaine.

Type 6 : Fait maison

Stack d'IA agentique construit en interne, éventuellement avec des frameworks open source auto-hébergés et exploités. Contrôle total sur toutes les couches, effort interne élevé.

La gouvernance en détail

Comme il n'y a pas de vendor pour le type 6, il n'y a au mieux que ce que les frameworks open source offrent. Par conséquent : pas de services managés, pas de surveillance, pas de journaux d'audit, pas d'outils de conformité, pas d'intervention humaine, pas de garde-fous.

L'organisation doit faire elle-même :

• Écrire des politiques OPA/Kyverno (par ex. l'agent ne peut pas lire de données PII sans masquage)
• Exploiter Keycloak/Auth0 (SSO, RBAC, cycle de vie utilisateur)
• Validation des sorties : Détection d'hallucination, filtres de contenu, vérifications de schéma JSON
• Mettre en place un stack ELK/Grafana (logs, métriques, alertes)
• Mettre en œuvre la journalisation d'audit
• Générer soi-même les rapports de conformité (BaFin-MaRisk, RGPD, GxP)
• Coder soi-même les workflows d'escalade
• Intégrer soi-même la protection contre l'injection de prompt (Lakera Guard ou règles personnalisées)

Adaptabilité des workflows & liberté des cas d'usage

• Conception des workflows : N'importe quel paradigme (machines à états, piloté par les événements, multi-agents, personnalisé)
• Sélection des cas d'usage : N'importe quel cas d'usage possible, aucune restriction de plateforme
• Intégrations : Chaque intégration est construite en interne, pas de limites de vendor
• Logique métier : Sans limites de plateforme, code personnalisé, règles personnalisées
• Scalabilité : Doit être gérée en interne (Kubernetes, répartition de charge), mais pas de plafond de coût de vendor
• Transformation de l'entreprise : Modèles économiques entièrement nouveaux possibles, la plateforme ne limite pas

En un coup d'œil

Conclusion

En travaillant sur cet article, j'ai réalisé que l'IA, dans le meilleur des cas, élargit la stratégie d'entreprise car elle permet de créer de nouveaux modèles économiques. Mais en même temps, la stratégie d'entreprise limite la stratégie d'IA.

Selon ma stratégie d'entreprise, je vais écarter certains types de stacks d'IA agentique.

La décision dépend de nombreux facteurs.

Il n'existe pas de modèle opérationnel « unique »

Vous avez certainement aussi réalisé en lisant que, selon le stack, vous avez besoin de rôles très différents pour le construire ou le mettre en œuvre, et finalement pour l'exploiter. Le développement est différent. La partie gouvernance est différente. Et si vous voulez créer de nouveaux modèles économiques, vous aurez peut-être besoin de rôles que vous n'aviez même pas envisagés.

Cela signifie que chaque type de stack d'IA agentique a des conséquences différentes pour l'organisation. Il en résulte :

• des modèles opérationnels différents
• des compositions d'équipes différentes
• des méthodes de travail différentes
• des conceptions organisationnelles différentes

Et il est très probable que vous ayez besoin de conseillers en IA différents pour chaque type.