La plupart des comparatifs de plateformes commencent par le coût des licences. C’est le mauvais point de départ — les frais de licence sont souvent la ligne la plus petite d’un budget sur trois ans.
La vraie différence entre les plateformes d’agents IA open source et propriétaires apparaît à trois endroits que les pages de tarifs des éditeurs ne mentionnent jamais : qui détient l’infrastructure par laquelle transitent les données de vos clients, qui contrôle la feuille de route de mise à jour lorsque la plateforme change de cap, et quelle capacité d’ingénierie interne vous devez mobiliser pour exploiter chaque option. Pour les entreprises suisses et de l’UE, une quatrième dimension amplifie les trois précédentes : les règles de résidence des données qui rendent certaines plateformes propriétaires opérationnellement difficiles, quelles que soient leurs fonctionnalités.
Cet article modélise ce tableau complet. L’objectif est un cadre de décision que vous pouvez appliquer à votre situation spécifique — non pas une recommandation qui ferait semblant que toutes les entreprises ont le même profil de risque.
Ce que « open source » et « propriétaire » signifient réellement pour les plateformes agentiques
Les étiquettes sont plus floues qu’il n’y paraît. Des frameworks comme LangGraph et CrewAI publient leur code principal sous des licences MIT permissives. Vous pouvez lire les sources, les héberger vous-même et les modifier sans payer personne. C’est une vraie ouverture. n8n emprunte une voie différente : il utilise une licence « fair-code » Sustainable Use qui restreint la redistribution commerciale et l’intégration sans accord enterprise payant — c’est du source-available plutôt que de l’open source au sens de l’OSI.
Les plateformes propriétaires — Microsoft Copilot Studio, Salesforce Agentforce, ServiceNow AI Agents et plusieurs outils de la catégorie startup — fournissent une infrastructure gérée, des connecteurs préconstruits et un SLA en échange d’un abonnement. Le runtime de l’agent tourne dans leur cloud ; vous configurez plutôt que vous ne construisez.
Une troisième catégorie complique le tableau : les fournisseurs de modèles open-weight (Mistral, la famille Llama de Meta) associés à une couche d’hébergement gérée. Vous obtenez les poids du modèle sous une licence source-available ou personnalisée — les modèles Mistral utilisent Apache 2.0 (genuinement permissif), tandis que la famille Llama de Meta utilise une licence communautaire personnalisée que l’Open Source Initiative ne reconnaît pas comme open source et qui comporte des restrictions pour les utilisateurs de l’UE — mais vous fonctionnez toujours sur la compute d’un tiers, à moins de vous auto-héberger. Pour les besoins de cette comparaison, nous traitons comme « propriétaire » tout arrangement où le runtime et le pipeline de données résident dans le cloud d’un éditeur selon ses conditions de service.
Le modèle TCO sur 3 ans : là où les chiffres divergent vraiment
Une entreprise de taille intermédiaire qui déploie son premier agent sérieux — disons une équipe opérationnelle de 50 personnes, faisant tourner trois workflows automatisés gérant au total 2 000 tâches par mois — fait face à une structure de coûts qui ressemble approximativement à ceci :
Parcours plateforme propriétaire
Les coûts de la première année sont faibles et prévisibles. Ils varient significativement selon la plateforme et le pattern d’utilisation — Microsoft Copilot Studio peut démarrer sous CHF 200/mois pour une utilisation légère des crédits (en complément des licences M365 de base obligatoires), tandis que Salesforce Agentforce à des tarifs par utilisateur peut dépasser CHF 3 000/mois même pour une petite équipe. Une fourchette de départ indicative pour une PME sur les grandes plateformes est de CHF 300–2 000/mois pour un usage agentique modéré, hors licences de base ; vérifiez les tarifs actuels sur les pages de prix des éditeurs avant de budgétiser, car ils changent fréquemment. Le délai d’implémentation se mesure en semaines plutôt qu’en mois. La plateforme gère l’hébergement, la mise à l’échelle, le monitoring et la gestion des versions de modèles ; la dépense totale de la première année, setup inclus, se situe typiquement entre CHF 20 000–50 000 selon la complexité d’intégration.
À la troisième année, le tableau change. Les frais à l’usage s’accumulent à mesure que vous étendez les workflows. Les plateformes propriétaires ont également tendance à renégocier les prix au renouvellement lorsqu’elles bénéficient d’un lock-in suffisant. Plus important encore : si la plateforme modifie son modèle d’exécution d’agents, déprécie une API ou est rachetée, vos workflows peuvent nécessiter une refonte coûteuse sur un code que vous ne pouvez pas forker.
Parcours framework open source
Les coûts de la première année sont concentrés en amont dans l’ingénierie. Un calendrier réaliste pour mettre en production un workflow agentique sur LangGraph ou CrewAI — incluant la mise en place de l’infrastructure, les outils d’observabilité, l’intégration des API LLM et les tests internes — est de 2 à 4 mois de temps développeur pour une équipe sans expérience préalable sur le framework. Aux tarifs actuels des prestataires suisses de CHF 100–200/heure (références de marché, mi-2026), cela représente CHF 40 000–120 000 avant que le premier workflow soit en production.
À la troisième année, le calcul s’inverse. Les coûts d’infrastructure d’un stack auto-hébergé sont en grande partie fixes. Il n’y a pas de frais par siège ou par exécution au-delà de vos coûts d’API LLM et de compute. Point crucial : vous possédez le code. La migration vers un autre fournisseur LLM, l’ajout d’une nouvelle intégration d’outil ou des modifications architecturales peuvent être réalisés sans conversation avec un éditeur.
Le point de croisement pour une PME typique se situe entre 18 et 30 mois — au-delà desquels le parcours open source tend à être moins coûteux sur une base de trésorerie pure, à condition que vous disposiez de la capacité d’ingénierie pour l’exploiter.
Résidence des données : pourquoi cela change la donne pour les acheteurs suisses et UE
C’est là que la comparaison passe du financier à l’existentiel pour de nombreuses entreprises suisses.
La nLPD (la loi fédérale révisée sur la protection des données en Suisse) et le RGPD imposent tous deux des obligations sur le lieu de traitement des données personnelles et sur qui peut y accéder. De nombreuses plateformes d’agents propriétaires traitent des données — notamment des transcriptions de conversations, des contenus de documents et des outputs de workflows — sur une infrastructure qui peut transiter par des serveurs basés aux États-Unis, soumis aux conditions des fournisseurs de cloud américains et potentiellement aux dispositions d’accès aux données du gouvernement américain.
Le risque pratique : si votre agent traite des dossiers d’employés, des communications clients, des données financières ou des informations à caractère médical, vous pourriez vous trouver dans une position délicate pour démontrer une protection adéquate des données si celles-ci transitent par une plateforme propriétaire gérée aux États-Unis. Certaines plateformes proposent des déploiements en région UE ; un nombre plus réduit offre de vraies garanties de traitement exclusivement UE. Encore moins peuvent répondre aux exigences spécifiquement suisses prévues par la nLPD.
Les frameworks open source, déployés sur une infrastructure suisse ou UE (un fournisseur cloud domestique, un serveur on-premises, ou une région UE Tier-1 avec des conditions DPA appropriées), vous offrent l’histoire la plus propre à présenter aux auditeurs et à votre propre délégué à la protection des données. Cette simplicité a une valeur réelle — non seulement dans l’évitement des contraintes de conformité, mais aussi dans le fait que vous pouvez effectivement démontrer les flux de données plutôt que de vous fier à l’attestation d’un éditeur.
Voir aussi : Agents IA et RGPD : déployer des automatisations défendables et Gouvernance des agents IA : un guide pratique pour les PME.
Lock-in au-delà du contrat : trois risques que les acheteurs propriétaires sous-évaluent
Le concept de lock-in des plateformes d’agents IA va plus loin que la plupart des acheteurs ne l’anticipent au moment de la signature.
Lock-in de la logique de workflow. La plupart des plateformes propriétaires utilisent un format de workflow visuel ou déclaratif qui n’est pas portable. Si vous construisez 40 automatisations sur la Plateforme A et souhaitez passer à la Plateforme B — ou à un stack personnalisé — vous repartez de zéro. Le coût irrécupérable de cette logique est bien réel.
Liaison au modèle. De nombreuses plateformes propriétaires restreignent les modèles que vous pouvez utiliser. Salesforce Agentforce propose désormais une option bring-your-own-LLM supportant Bedrock, Azure OpenAI et Google Vertex AI, et Microsoft Copilot Studio supporte des connexions Azure OpenAI personnalisées — mais les deux vous contraignent toujours à des listes de fournisseurs pré-approuvés et facturent des frais de plateforme quel que soit le modèle utilisé. Les outils propriétaires de la catégorie startup imposent généralement des restrictions plus strictes. Les frameworks open source sont généralement model-agnostic.
Opacité de l’observabilité. Lorsqu’un agent se comporte de façon inattendue sur une plateforme propriétaire, votre surface de débogage est limitée à ce que l’éditeur expose dans ses logs et outils de trace. Sur un stack open source, vous instrumentez exactement ce dont vous avez besoin — et vous possédez ces données de télémétrie.
Compétences internes : un prérequis à évaluer honnêtement
Open source ne signifie pas « gratuit en termes de coût humain ». Les frameworks qui vous donnent le plus de contrôle — le modèle de graphe avec état de LangGraph, par exemple — ont des courbes d’apprentissage significatives. Exploiter un stack d’agents en production nécessite des compétences en :
- Python ou TypeScript (selon le framework)
- Intégration d’API LLM et prompt engineering
- Orchestration de conteneurs (Docker au minimum, Kubernetes si la scale l’exige)
- Outils d’observabilité (logging, tracing, alerting)
- Durcissement de la sécurité pour l’accès des agents aux outils
Si votre équipe ne dispose d’aucune de ces compétences, l’estimation de coût pour la première année ci-dessus sous-estime la réalité de façon significative. L’écart est comblé par du recrutement, de la sous-traitance ou un partenaire spécialisé — mais il existe et doit être chiffré.
Les plateformes propriétaires abaissent substantiellement cette barre. Une personne opérationnelle techniquement compétente — pas un ingénieur logiciel — peut construire et maintenir des automatisations significatives sur une plateforme gérée bien conçue. C’est un avantage réel, pas du marketing.
Qui devrait choisir quoi
L’open source est le meilleur choix quand :
- Les exigences de résidence des données sont strictes et vous avez besoin d’une documentation auditable des flux de données
- Vous prévoyez que l’empreinte agentique va croître significativement sur 2–3 ans (l’avantage TCO s’accumule)
- Vous disposez ou pouvez recruter une capacité d’ingénierie pour exploiter le stack
- Vous avez besoin de flexibilité sur les modèles ou d’intégrations d’outils personnalisées au-delà de ce qu’exposent les plateformes gérées
- Vous construisez un produit ou un service sur la base d’agents (la propriété intellectuelle est un enjeu)
Le propriétaire est le meilleur choix quand :
- La rapidité pour obtenir une première automatisation fonctionnelle compte plus que la flexibilité à long terme
- Votre cas d’usage s’adapte parfaitement à la bibliothèque de connecteurs préconstruits de la plateforme
- Vous ne disposez pas de la bande passante d’ingénierie pour exploiter et maintenir une infrastructure
- Les workflows que vous automatisez n’impliquent pas de données personnelles sensibles — ou votre plateforme de choix offre des garanties crédibles de traitement uniquement UE/CH
Des voies hybrides existent. Certaines organisations utilisent des plateformes propriétaires pour des automatisations peu sensibles et peu complexes — planning interne, routage de documents sans données personnelles — tout en conservant un stack open source auto-hébergé pour tout ce qui touche des données réglementées. Cela ajoute de la complexité opérationnelle mais distribue le risque de façon sensée.
Pour un cadrage plus large de la dimension build-versus-buy, voir Build vs Buy : un cadre de décision pour les agents IA.
Là où un partenaire change l’équation
L’avantage TCO de l’open source est réel, mais il dépend du fait que l’investissement d’ingénierie de la première année soit correctement réalisé. Une mauvaise décision architecturale dès le départ — le mauvais framework pour votre cas d’usage, un setup d’observabilité insuffisant, un modèle de données qui ne tient pas compte de la montée en charge future — efface rapidement l’avantage.
Travailler avec un spécialiste qui a déjà construit et exploité des stacks d’agents open source en production signifie que vous ne payez pas pour la courbe d’apprentissage de quelqu’un. Vous payez pour un pattern qui fonctionne déjà, appliqué à vos workflows spécifiques et à votre environnement de données.
C’est précisément le travail que nous faisons chez Orange ITS. Notre practice de développement d’agents IA est framework-agnostique : nous choisissons le bon outil en fonction de la maturité technique du client, du contexte réglementaire et de la trajectoire de croissance — ce qui signifie parfois recommander une plateforme gérée, et parfois construire sur de l’open source. Nous n’avons aucun intérêt commercial à pousser l’une ou l’autre voie.
Prêt à adapter ce cadre à votre situation ?
Le cadre ci-dessus réduit l’espace de décision, mais la bonne réponse dépend encore de vos workflows spécifiques, de votre classification des données, du profil technique de votre équipe et de vos plans de croissance.
Un appel de 30 minutes avec notre équipe suffit pour identifier la voie qui vous correspond — et pour estimer le coût réel sur 3 ans pour votre scénario plutôt qu’un modèle générique. Contactez Orange ITS pour planifier cet échange.