Former à l'IA générative sans en construire est confortable : on commente les annonces, on compare des interfaces, on rappelle les bonnes pratiques. Concevoir et exploiter une plateforme d'IA agentique est une autre affaire. Il faut trancher, documenter ses choix, et vivre avec leurs conséquences en production.

C'est ce que nous faisons avec Dynamov.ai, plateforme IA agentique européenne pour PME et ETI, fondée par Grégoire Semelet, également fondateur de MaCertif et formateur sur nos parcours IA. Cet article expose quatre décisions d'architecture que ce travail nous a imposées, et ce que chacune a changé dans nos formations.

1. La souveraineté n'est pas binaire : elle se règle par cas d'usage

La question « nos données partent-elles aux États-Unis ? » appelle rarement une réponse unique. Une note de synthèse publique et un dossier RH n'exposent pas au même risque. Une politique « tout souverain » est intenable à l'usage, et une politique « tout best-in-class » est intenable juridiquement.

Le choix retenu a donc été une souveraineté configurable, modèle par modèle : des modèles européens hébergés en Europe (Mistral en France, Qwen3 et GLM en Finlande) pour les données sensibles, des modèles internationaux pour les tâches qui le justifient, et une politique de résidence des données à trois niveaux — flexible, journalisation de chaque appel hors UE pour le DPO, ou blocage strict à l'exécution.

Le point qui compte est le dernier : un blocage à l'exécution, pas un affichage. Une interface qui recommande un modèle européen sans l'imposer côté serveur ne protège rien dès qu'un utilisateur clique ailleurs. C'est la différence entre une intention et un contrôle — et c'est précisément ce que vérifie un auditeur.

Ce que nous en enseignons : dans le parcours Agents IA, automatisations et déploiement souverains, les participants cartographient leurs flux et classent leurs cas d'usage par sensibilité avant de choisir un modèle. L'arbitrage précède l'outil.

‍

‍

2. Protéger les données demande deux barrières, pas une

Un filtre d'anonymisation en amont détecte noms, e-mails, téléphones, IBAN, SIRET et identifiants clients, et les remplace par des marqueurs avant l'envoi au modèle ; les vraies valeurs sont réinsérées à l'affichage, pour l'utilisateur seulement. C'est nécessaire, et insuffisant : aucune détection n'est exhaustive, et un secret professionnel ne ressemble pas toujours à une donnée personnelle.

D'où la seconde barrière : une analyse transversale a posteriori des conversations par un modèle souverain, qui cherche les fuites résiduelles et les comportements à risque. La première barrière empêche, la seconde constate. Renoncer à la seconde revient à supposer que la première ne se trompe jamais.

Deux conséquences pratiques en découlent. Le masquage doit pouvoir être imposé côté serveur, sinon il se contourne. Et la conversation stockée doit conserver les marqueurs : si la base contient les valeurs réelles, le travail d'anonymisation ne protège que le trajet vers le modèle.

Ce que nous en enseignons : le module « sécurité des agents » traite l'injection de prompt en la reproduisant, puis la gestion des secrets, les périmètres d'action et la journalisation. Les participants repartent avec une checklist de mise en production.

‍

‍

3. Un agent qui agit a besoin d'un humain qui valide

Un agent capable de lire une boîte mail et d'y répondre seul est une démonstration impressionnante et un risque opérationnel mal placé. Le choix a été de ne jamais envoyer automatiquement : l'agent classe, rédige, joint les bonnes pièces, dépose un brouillon — un humain relit et envoie.

Le même principe vaut pour les workflows multi-étapes : une étape de validation suspend l'exécution jusqu'à décision, et cette décision — qui, quand, avec quel commentaire — est tracée au même titre qu'un accès exceptionnel. Sans cette trace, personne ne peut reconstituer qui a laissé passer quoi.

Ce que nous en enseignons : la distinction entre automatisme, assistant et agent est posée dès le premier module, avec une règle simple — plus l'action est irréversible, plus le point de contrôle humain doit être explicite.

‍

‍

4. Les coûts dérivent par les volumes, pas par les tarifs

Entre un modèle économique et un modèle premium, l'écart de prix va de 1 à 50. Rédiger un e-mail courant avec le modèle le plus puissant ne produit pas un e-mail cinquante fois meilleur ; multiplié par les volumes, l'enjeu budgétaire devient pourtant considérable.

Trois garde-fous se sont révélés indispensables : le coût réel affiché sous chaque réponse — une mesure, pas une estimation ; un plafond mensuel par utilisateur et par agent, pour qu'un agent emballé n'épuise pas le budget de toute l'organisation ; et un disjoncteur qui désactive une automatisation au franchissement d'un seuil quotidien, avec réarmement manuel. Un réarmement automatique ne serait qu'un délai avant la même dérive.

Ce que nous en enseignons : chiffrer le gain attendu avant d'écrire la première ligne, et mesurer le coût réel après. Une automatisation dont personne ne connaît le coût n'est pas pilotée.

‍

‍

Ce que cela change pour une formation

Ces quatre décisions ont un point commun : aucune ne s'invente en salle. Elles viennent de contraintes réelles — un DPO qui demande des preuves, une facture qui surprend, un agent qui agit trop vite. C'est la raison pour laquelle nos parcours IA sont révisés chaque trimestre et travaillés sur des cas d'usage apportés par les participants, avec un livrable qui fonctionne à la fin de chaque séance.

Nous le précisons par souci de transparence : Dynamov est éditée par votre formateur. Les autres outils du parcours — n8n, Make, Mistral, Claude — sont traités avec la même rigueur, et vous saurez à chaque fois où partent vos données et ce que cela implique.

Pour aller plus loin : découvrez le parcours Agents IA, automatisations et déploiement souverains, ou la plateforme Dynamov.ai.