> ## Content Index > Fetch the complete content index at: https://mauricemendy.com/llms.txt > Use this file to discover other available public pages before exploring further. # Acheter ou construire, la comparaison frontale - URL: https://mauricemendy.com/acheter-ou-construire-la-comparaison-frontale/ - Published: 2026-09-22T11:28:05.000Z - Updated: 2026-09-22T11:28:05.000Z - Author: Maurice MENDY - Tags: stratégie IA entreprise, agents IA *Série stratégie IA d'entreprise — 4/5* Une organisation qui a déployé un SaaS multi-provider pendant dix-huit à vingt-quatre mois finit par voir apparaître les quatre limites posées [en fin d'article précédent](https://mauricemendy.com/le-multi-provider-saas/). Le pricing par siège devient une ligne budgétaire significative à l'échelle. Un cas d'usage métier différenciant demande un contrôle plus fin que ne le permet la plateforme. La portabilité des agents construits sur trois ans se pose comme un projet en soi. Et pour certains secteurs, la souveraineté sur les données interdit toute forme d'externalisation. La question posée par ces quatre limites est claire. Est-ce le moment de construire sa propre couche multi-provider en interne ? La bonne réponse dépend de facteurs très concrets, et se dessine assez précisément une fois qu'on les regarde en face. ## Ce qui déclenche la bascule Quatre vrais déclencheurs poussent une organisation à construire sa propre couche. L'économie à l'échelle vient en premier. Un SaaS multi-provider facturé autour de 25 à 30 euros par siège absorbe sans difficulté 500 utilisateurs. À plusieurs milliers, la ligne budgétaire annuelle devient significative, et la question du retour sur investissement d'une construction interne se pose légitimement. Vient ensuite l'apparition d'un cas d'usage métier différenciant qui ne rentre plus dans le cadre d'un SaaS générique. Un modèle propriétaire affiné sur des données maison, un pipeline agentique qui manipule des documents réglementés, un assistant spécialisé sur un produit unique. Un troisième axe est réglementaire. Certaines contraintes de souveraineté et de compliance interdisent structurellement l'externalisation, quel que soit le fournisseur SaaS. La défense, une partie du secteur public, la santé sur données patient, certains cas de la finance. Le dernier déclencheur est la maturité IA interne. Sans équipe technique capable de porter le projet, aucun des trois premiers ne se traduit en résultat. En face de ces vrais déclencheurs, deux faux signaux mènent régulièrement à la mauvaise décision. L'orgueil technique et le syndrome Not Invented Here font croire qu'une équipe interne fera forcément mieux qu'un éditeur spécialisé, alors que ce dernier a passé plusieurs années à polir sa plateforme. La sous-estimation systématique des coûts totaux transforme la comparaison en équation biaisée, dont la partie visible (le pricing SaaS évité) masque une partie invisible autrement plus lourde. ## Ce que construire veut vraiment dire Construire une couche multi-provider en interne consiste à assembler plusieurs composants techniques dont le poids varie selon les choix d'architecture. Une précision s'impose avant d'aller plus loin : construire ne signifie jamais héberger soi-même les modèles. Ce que l'organisation possède, c'est la couche d'orchestration, à savoir le routage, la sécurité, l'observabilité, les connecteurs métier, pas les poids du modèle lui-même, qui continue d'être appelé chez un fournisseur externe. Cette distinction structure tout ce qui suit. Trois approches structurent la partie basse de la stack. La première s'appuie sur un routeur commercial comme OpenRouter, qui expose plus de 400 modèles derrière une API compatible OpenAI, avec BYOK sur les clés Anthropic et OpenAI, et prend en charge la partie routage et normalisation. C'est le chemin le plus court parce qu'il élimine la partie basse du chantier. La seconde utilise un projet open source auto-hébergé comme LiteLLM, avec un contrôle total sur le code et l'hébergement, contre une maintenance à porter en propre. La troisième construit une gateway maison à partir de zéro, avec le plus haut niveau de contrôle et le plus haut coût. Ce cas reste réservé à quelques acteurs très mûrs : certaines banques, quelques industriels, les hyperscalers pour leur usage interne ![Trois approches pour construire la partie basse d'une couche multi-provider : routeur commercial (OpenRouter), open source auto-hébergé (LiteLLM), gateway maison](https://mauricemendy.com/content/images/2026/08/trois-approches-routage-2.png) Le routeur ne résout pas l'intégralité du chantier, mais il en couvre davantage que le seul routage. LiteLLM et OpenRouter embarquent nativement du fallback entre fournisseurs et un suivi de consommation par équipe ou par clé API. Ce qui reste au-dessus, une fois ces briques natives posées, transforme cet accès technique en plateforme utilisable par une organisation : une gestion fine de l'identité (SSO, contrôle d'accès par rôle), une observabilité intégrée à la stack de monitoring déjà en place, la conformité et l'audit au niveau attendu par l'entreprise, l'interface utilisateur, les connecteurs métier, le pilotage budgétaire consolidé par équipe. Chacun de ces éléments demande une conception dédiée, une intégration, et une maintenance dans la durée. L'expérience de terrain montre qu'un routeur ou une gateway ne représente qu'**environ 20 à 30 % du travail total** d'une plateforme IA d'entreprise sérieuse. ![Stack complète d'une plateforme IA d'entreprise : le routeur ne représente que 20 à 30 pour cent du travail total, le reste est sécurité, observabilité, UX, connecteurs, gouvernance](https://mauricemendy.com/content/images/2026/08/stack-plateforme-ia-2.png) Air France-KLM illustre un cas européen documenté de construction interne assumée. Le groupe, qui compte plus de 75 000 salariés, a officialisé en juillet 2025 sa Gen AI Factory, une plateforme construite avec Google Cloud comme infrastructure et Accenture comme intégrateur. Le choix éclaire deux points. D'abord, construire ne signifie pas nécessairement réinventer la roue jusqu'aux fondamentaux. Air France-KLM s'appuie sur une couche cloud et un intégrateur pour absorber la partie basse, tout en gardant la maîtrise de sa plateforme au-dessus. Ensuite, les cas d'usage ciblés (ground operations, maintenance aéronautique, service client) sont différenciants pour un opérateur aérien et justifient l'investissement dans une plateforme sur mesure. Julie Pozzi, Head of Data & AI du groupe, décrit l'objectif comme une transformation opérationnelle plus qu'une innovation technique. L'échelle du groupe, l'unicité des cas d'usage, et la maturité IA interne combinent trois des quatre déclencheurs identifiés plus haut. > Un autre cas français, celui d'Air Liquide, éclaire une nuance plus représentative de la réalité des grandes organisations. Le groupe (plus de 60 000 salariés, l'IA dans les processus industriels depuis près de trente ans) déploie deux couches d'abstraction en parallèle. Google Workspace avec Gemini couvre l'usage bureautique standard, dans la logique du mono-provider bundlé. En parallèle, le groupe construit un Hub LLM multi-technologies pour ses projets d'IA générative et agentique. Le premier cas d'usage cité par Fabien Mangeant, Chief Data & AI Officer, illustre pourquoi cette seconde couche est justifiée : un assistant pour les équipes financières, préparant l'automatisation d'une partie des millions de transactions annuelles. On est loin de la synthèse d'email ou du résumé de réunion. C'est précisément le type de cas d'usage métier différenciant qui justifie la construction. ## Le profil en cinq axes Appliqué à la grille en cinq axes posée dans [l'article de cadrage](https://mauricemendy.com/larchitecture-avant-le-modele/), le multi-provider construit en interne dessine un profil radicalement asymétrique de ceux des deux autres familles. ![Profil en cinq axes du multi-provider construit en interne : agilité et gouvernance maximales, expérience utilisateur en retrait](https://mauricemendy.com/content/images/2026/08/grille-4-multi-provider-interne.png) L'agilité et la gouvernance sont poussées au maximum. Une fois un nouveau modèle qualifié en interne (sécurité, propriété intellectuelle, performance sur les cas d'usage cibles, conformité), l'organisation dispose de la capacité technique de l'intégrer à son propre rythme, sans attendre qu'un éditeur SaaS le fasse pour elle. La gouvernance suit la même logique : construite sur mesure, granulaire, alignée sur les politiques internes et le secteur d'activité. Le coût total de possession est déplacé du siège vers l'infrastructure et les compétences. La résilience est portée en propre, ce qui la rend techniquement contrôlable mais opérationnellement exigeante. L'expérience utilisateur, enfin, est le point faible structurel de cette famille. Sans un investissement UX comparable à celui des éditeurs SaaS matures, l'interface interne reste souvent moins polie, ce qui pèse sur l'adoption par les métiers non techniques. ## La comparaison axe par axe La comparaison entre acheter une couche spécialisée (le SaaS multi-provider déployé à l'étape précédente) et construire une couche en interne (le classique Build vs Buy des DSI) se lit sur les cinq axes de la grille, avec des trajectoires très différentes selon l'axe considéré. Le coût total de possession est le premier axe où la comparaison se joue. Le SaaS est linéaire par siège, prévisible sur deux à trois ans, mais sa ligne budgétaire explose au-delà de **plusieurs milliers d'utilisateurs**. La construction interne demande un investissement initial élevé (équipe, infrastructure) avec un coût marginal faible ensuite. Le point de bascule économique se situe pédagogiquement autour de plusieurs milliers de sièges, avec une variance importante selon l'intensité d'usage. ![Point de bascule économique entre SaaS multi-provider et construction interne, situé autour de plusieurs milliers de sièges avec forte variance selon l'usage](https://mauricemendy.com/content/images/2026/08/point-de-bascule-economique.png) En matière de gouvernance, l'écart est de nature. Le SaaS livre une gouvernance achetée, standardisée, éprouvée par d'autres clients, mais bornée par ce que l'éditeur choisit d'exposer. La construction interne produit une gouvernance sur mesure, alignée précisément sur les politiques internes, à condition d'accepter d'en porter la maintenance dans la durée. L'agilité penche nettement vers l'interne. Un SaaS reste borné par le catalogue et le rythme d'intégration du fournisseur. Une équipe interne peut intégrer un nouveau modèle dès que celui-ci a passé son processus de qualification interne (sécurité, propriété intellectuelle, performance, conformité), sans dépendre en plus du calendrier d'un éditeur tiers. Cette agilité peut être décisive dans un marché où les modèles évoluent tous les deux à trois mois. La résilience prend un contour plus subtil. Le SaaS offre une résilience contractuellement encadrée, avec des SLA et une équipe support qui prend en charge les incidents. L'interne offre une résilience techniquement contrôlée, avec des fallbacks maison et une équipe qui les maintient. La différence porte concrètement sur qui répond à trois heures du matin quand un modèle tombe. L'expérience utilisateur, en revanche, revient au SaaS. Les éditeurs matures ont passé plusieurs années à polir leurs interfaces, à intégrer les retours des utilisateurs métiers, à optimiser les parcours. Une équipe interne peut atteindre le même niveau, mais l'investissement UX nécessaire est fréquemment sous-estimé au moment du cadrage initial. ## Ce que les DSI sous-estiment le plus Cinq coûts cachés apparaissent systématiquement dans les projets de construction interne. L'équipe plateforme IA vient en premier. Une construction sérieuse demande un ensemble pluridisciplinaire : lead technique, ingénieurs plateforme, sécurité, UX, chef de produit, ML dédié selon les cas d'usage. Le recrutement de ces profils reste tendu sur le marché français, et leur rémunération pèse durablement sur le coût annuel de la plateforme. La maintenance continue arrive juste derrière. Les modèles évoluent tous les deux à trois mois, les APIs des fournisseurs changent, les nouveaux formats de fonctionnalités (tool use, structured outputs, extended thinking) demandent des adaptations. Une couche interne implique une veille et une intégration continues, sans le levier d'un fournisseur SaaS qui absorberait ce travail. La compliance et l'audit se portent en propre. L'entreprise construit et maintient elle-même les logs, les rapports d'audit, les évaluations de conformité RGPD et AI Act. Ce travail est loin d'être trivial pour une organisation qui n'a jamais eu à le faire dans ce périmètre. La migration des cas d'usage existants représente un projet en soi, particulièrement pour une organisation qui a construit des dizaines ou centaines d'agents sur une plateforme SaaS avant de basculer. Le support interne est l'angle le plus fréquemment oublié. Les utilisateurs poseront des questions, rencontreront des bugs, feront remonter des demandes d'exception. La plateforme interne doit prévoir cette fonction dès la conception, sous peine de voir émerger un shadow IA que l'équipe n'a pas anticipé. ## Le bon choix, pour quel profil Le multi-provider construit en interne est le bon choix architectural pour un profil d'organisation qui se dessine assez précisément. Une grande entreprise, typiquement au-dessus de plusieurs milliers de salariés utilisateurs, dispose d'un ordre de grandeur d'usage qui justifie l'investissement. Une équipe technique mature et disponible, avec une capacité de recrutement effective sur des profils IA, permet de porter le projet dans la durée. Des contraintes de souveraineté ou de compliance particulières (défense, secteur public sensible, santé sur données patient, finance sur certains cas) rendent l'externalisation impraticable. Un ou plusieurs cas d'usage IA différenciants critiques pour l'activité justifient une plateforme sur mesure. Des volumes de tokens élevés, mesurés en millions ou milliards par mois, rendent le coût marginal plus attractif que la facturation par siège. Un cas hybride mérite d'être rappelé. Certaines organisations juxtaposent une couche mono-provider pour le bureautique et une construction interne pour les cas d'usage différenciants, comme l'illustre le cas Air Liquide décrit plus haut. Ce compromis absorbe une partie du poids technique tout en gardant la maîtrise des cas d'usage métier. ## Ce que cette série a posé Les trois familles d'architecture IA d'entreprise sont désormais posées, chacune avec son profil pentagonal. Aucune ne domine sur l'ensemble des cinq axes. Le choix d'architecture est un arbitrage entre coût, gouvernance, agilité, résilience et expérience utilisateur : entre acheter (le mono-provider bundlé), acheter une couche spécialisée (le SaaS multi-provider) et construire (l'interne), selon le profil réel de l'organisation. Le cas Air Liquide rappelle également qu'une grande organisation peut faire coexister plusieurs de ces architectures selon la nature des usages, ce que l'article 5 intégrera dans sa matrice de décision. À suivre : la matrice de décision qui permet de choisir sa famille selon son profil d'entreprise. Taille, secteur, maturité IA interne, contraintes réglementaires, volumétrie, horizon d'usage. Article 5 : le morceau le plus actionnable de la série, avec la matrice et la checklist pour arbitrer.