Dots agents d'OpenAI : trois architectures pour ne pas subir la prochaine hausse

# Dots agents d'OpenAI : trois architectures pour ne pas subir la prochaine hausse

Les Dots agents d'OpenAI ne sont pas une innovation neutre. Ce sont un mécanisme de verrouillage. Derrière l'ergonomie et la promesse d'orchestration avancée, la réalité budgétaire pour une PME européenne est simple : chaque action, chaque appel, chaque décision de l'agent passe par une infrastructure dont vous ne maîtrisez ni le coût, ni la roadmap, ni la localisation des données. En 2026, après plusieurs cycles de révision tarifaire unilatérale, continuer à construire ses flux d'automatisation sur cette base relève moins d'un choix technique que d'une dépendance non assumée.

Ce comparatif ne cherche pas à disqualifier l'approche américaine par principe. Il pose une question concrète pour le DSI ou le CTO d'une ETI européenne : quelles architectures permettent aujourd'hui de déployer des agents capables, tout en gardant la gouvernance des données, la prévisibilité des coûts et la capacité à changer d'aile en cas de nouvelle vague tarifaire ?

Trois approches sont comparées ici sur quatre critères : architecture d'orchestration, intégration SI, gouvernance des données, et résilience budgétaire.

Les trois approches comparées

Approche A — Agent-as-a-Service US (référence Dots/OpenAI)

L'architecture native proposée par l'acteur américain dominant : orchestration cloud-centrée, modèle de fondation propriétaire, API first, déploiement entièrement géré côté fournisseur.

Approche B — Stack ouverte auto-hébergée (ex. : LangGraph + modèle open-weight hébergé chez un cloud européen certifié)

Orchestration via framework open source, modèle de langage déployé sur infrastructure européenne souveraine, intégration SI via connecteurs standards.

Approche C — Plateforme agent européenne managée (ex. : Dust.tt, éditeur français, ou équivalent DACH)

SaaS européen spécialisé agent, conçu pour l'entreprise, avec engagement contractuel sur la localisation des données et une gouvernance explicite.

Critère 1 — Architecture d'orchestration

| Dimension | Approche A (US dominant) | Approche B (open-weight auto-hébergé) | Approche C (SaaS EU managé) |

|---|---|---|---|

| Modèle d'orchestration | Propriétaire, opaque | Configurable, code-first | Configurable, interface low-code |

| Portabilité des workflows | Faible (lock-in format) | Haute (standard ouvert) | Moyenne (dépend de l'éditeur) |

| Capacité multi-modèle | Limitée à l'écosystème US | Native | Variable selon plateforme |

| Contrôle de la logique agent | Partiel (guardrails imposés) | Total | Partiel (selon niveau SaaS) |

Ce que ça change pour vous. L'approche A impose une logique d'orchestration que vous subissez : les guardrails, les limites de contexte, les comportements par défaut sont décidés à San Francisco. Si OpenAI modifie le comportement du modèle sous-jacent — ce qui arrive à chaque version — vos workflows peuvent dériver sans que vous en soyez informés formellement. L'approche B vous donne un contrôle total, au prix d'une charge d'ingénierie réelle. L'approche C cherche à trouver l'équilibre, mais la qualité de cette promesse dépend fortement de la maturité de l'éditeur choisi.

Critère 2 — Intégration SI

| Dimension | Approche A | Approche B | Approche C |

|---|---|---|---|

| Connecteurs natifs ERP/CRM | Nombreux, mais US-centric | À construire (effort dev) | Souvent orientés outils EU |

| Conformité RGPD by design | Non (engagement contractuel insuffisant) | Oui si hébergement EU maîtrisé | Oui (engagement contractuel EU) |

| Latence et disponibilité | Dépend des datacenters US | Maîtrisée | Variable selon hébergeur |

| Capacité d'audit des flux | Limitée | Totale | Partielle à totale |

Ce que ça change pour vous. Le point d'intégration SI est souvent là où le verrouillage commence vraiment. Les connecteurs natifs de l'acteur américain dominant sont nombreux, mais ils ont été conçus pour un écosystème pensé aux États-Unis. Si votre ERP est un acteur européen — Cegid, SAP (déploiement on-prem), ou une solution sectorielle française ou allemande —, l'intégration avec les Dots agents demandera de toute façon du travail custom. Autant faire ce travail une fois, sur une architecture que vous contrôlez. L'approche B impose un effort initial plus important, mais chaque connecteur développé reste dans votre patrimoine technique. L'approche C peut raccourcir ce délai si l'éditeur a déjà investi sur les connecteurs pertinents pour votre secteur.

Critère 3 — Gouvernance des données

C'est ici que le débat technique rejoint le débat stratégique — et budgétaire.

Avec l'approche A, vos données d'entreprise — requêtes des agents, contexte métier injecté, résultats intermédiaires — transitent et sont temporairement traitées sur infrastructure américaine. Les engagements contractuels d'OpenAI ont évolué, mais ils restent soumis au droit américain, notamment au Cloud Act. Pour une PME industrielle avec des données de conception, une ETI dans le secteur de la santé ou de la finance, ou toute entreprise travaillant avec des donneurs d'ordre soumis à NIS2, ce n'est pas un risque théorique.

L'approche B, bien configurée, vous permet de garantir que rien ne sort de votre périmètre — ni vers un fournisseur de modèle américain, ni vers un broker tiers. C'est la seule architecture qui offre une souveraineté technique complète. Mais elle exige une équipe capable de la maintenir.

L'approche C repose sur la confiance contractuelle envers l'éditeur européen. C'est moins fort techniquement que l'auto-hébergement, mais infiniment plus solide juridiquement et opérationnellement que de s'en remettre à l'acteur américain dominant. Le point de vigilance : vérifier que l'éditeur SaaS EU ne s'appuie pas lui-même sur AWS, Azure ou GCP pour son infrastructure de base — ce qui reviendrait à déléguer la souveraineté par une porte dérobée.

Critère 4 — Résilience budgétaire

Pas de tarifs dans ce comparatif — ils changent trop vite pour être utiles. Ce qui compte pour le DSI, c'est la structure de risque, pas le coût affiché aujourd'hui.

| Dimension | Approche A | Approche B | Approche C |

|---|---|---|---|

| Prévisibilité des coûts à 18 mois | Faible (historique de révisions) | Haute (infrastructure maîtrisée) | Moyenne à haute |

| Pouvoir de négociation | Nul (prix fixing US) | Élevé (multi-fournisseur possible) | Moyen (relation éditeur EU) |

| Coût de sortie | Très élevé (lock-in) | Faible (open source) | Moyen |

| Exposition aux décisions réglementaires US | Directe | Nulle | Faible |

Le durcissement tarifaire des Dots agents n'est pas un accident : c'est un signal de maturité du marché américain. OpenAI a établi sa base installée, les alternatives gratuites ou quasi-gratuites de la phase de conquête se referment. La valeur est maintenant extraite. C'est le cycle classique des plateformes en position dominante. Les PME et ETI européennes qui ont construit leurs workflows d'automatisation sur cette base se retrouvent dans la position du locataire qui découvre que le propriétaire a changé les règles du bail.

L'approche B maximise la résilience budgétaire mais déplace le coût vers l'ingénierie interne. Pour une ETI sans équipe IA dédiée, c'est souvent irréaliste à court terme. L'approche C offre un compromis opérationnel viable : un éditeur européen a des intérêts alignés avec les siens — il ne peut pas se permettre de vous perdre comme client, et il est soumis au même cadre réglementaire que vous.

Ce que le DSI doit faire maintenant

La question n'est pas de savoir si les Dots agents sont techniquement compétents. Ils le sont. La question est de savoir si vous acceptez de construire une dépendance opérationnelle sur une infrastructure dont vous ne contrôlez ni l'évolution tarifaire, ni la localisation des données, ni la continuité réglementaire.

Le mouvement concret : auditer dès maintenant quels workflows sont déjà en production sur des agents OpenAI — souvent via des intégrations Shadow IT que les équipes métier ont déployées sans validation DSI — et identifier lesquels portent des données sensibles ou sont devenus critiques pour l'opérationnel. Ce sont les cas d'usage à migrer en priorité vers l'approche B ou C.

La transition n'est pas idéologique. Elle est de bonne gestion du risque fournisseur.