Mutualiser l’IA : que faut-il réellement mettre en commun ?

Par Pascal Chevallot, avec l’appui de son harnais d’IA
17 août 2026

La mutualisation de l’intelligence artificielle entre collectivités n’est plus une hypothèse. Des services publics se structurent, un financement national encourage les achats groupés et, sur le terrain, plusieurs organisations testent aussi bien des solutions du marché que leurs propres flux de travail. Le choix n’oppose donc pas une plateforme commune à une série d’achats isolés. Il porte sur la capacité publique que l’on veut construire, partager et conserver.

Le mot « mutualisation » peut donner l’impression que l’essentiel se joue dans le volume : regrouper des licences, partager une infrastructure, répartir une dépense. Ces leviers comptent. Ils ne suffisent pas à répondre aux questions qui apparaissent dès qu’un outil entre dans un processus réel : qui qualifie le besoin, contrôle le résultat, traite un incident, maintient le flux de travail et décide de suspendre l’usage ?

Ces derniers mois, plusieurs signaux ont rendu cette discussion beaucoup plus concrète. Ils dessinent moins un modèle unique qu’un éventail de choix : recourir à un service public mutualisé, acheter une solution, construire certaines capacités en interne ou combiner ces voies.

Le terrain a devancé la plateforme idéale

En Bourgogne-Franche-Comté, l’ARNIa a développé CmonIA, un agent conversationnel conçu pour les acteurs publics. L’agence indique utiliser des modèles fournis par Mistral AI et héberger les données des utilisateurs en Bourgogne-Franche-Comté. L’offre associe l’outil à des formations, des ateliers, un MOOC, des expérimentations et des Clubs IA. C’est déjà davantage qu’un accès partagé à un modèle : un service, un accompagnement et un cadre d’apprentissage.

L’ARNIa explique par ailleurs travailler au quotidien avec d’autres opérateurs publics de services numériques présents partout en France. Elle présente cette coopération comme un moyen de confronter les expériences, de partager les pratiques utiles et d’éviter que chaque territoire développe seul les mêmes réponses.

Le passage d’une coopération à un service commun changerait pourtant la nature de la mutualisation. Il déplacerait le pouvoir de choisir les outils, les priorités et le rythme des évolutions. Les plus petites collectivités pourraient gagner un accès qu’elles n’auraient pas seules, tout en voyant leurs besoins minoritaires relégués derrière ceux des membres les mieux dotés. Une gouvernance représentative, un droit de ne pas activer certains usages et des conditions de sortie praticables devraient alors faire partie du service commun.

À l’échelle de l’État, Albert API fournit un autre point de comparaison. La DINUM le présente comme une infrastructure mutualisée donnant accès à plusieurs modèles génératifs et à des fonctions de recherche documentaire, d’OCR, de classification ou de vectorisation. Albert API est toujours opérationnel ; le catalogue public mentionne notamment des modèles d’OpenAI, Mistral AI, Alibaba/Qwen et, en expérimentation, DeepSeek. Une infrastructure opérée en France peut donc agréger des modèles d’origines diverses.

Cette logique de catalogue gagne désormais le marché européen. En août 2026, Mistral AI a annoncé l’ouverture de sa plateforme à des modèles tiers, en commençant par GLM-5.2 de l’acteur chinois Z.ai. La nouveauté ne réside pas dans la possibilité technique de déployer un modèle aux poids ouverts. Elle tient à son intégration dans une offre managée qui associe contrôle régional de l’inférence, interface commune, supervision, capacité et niveau de service.

Cette évolution a suscité une critique publique de Michel-Marie Maudet, directeur général de LINAGORA, une entreprise elle-même engagée avec OpenLLM France dans le développement de modèles ouverts. Il y voit le déplacement de la valeur, des modèles vers la couche de distribution, et alerte sur les dépendances que peuvent créer les services managés. Cette critique éclaire une divergence de fond entre deux conceptions de la souveraineté : l’une privilégie une infrastructure européenne capable d’opérer différents modèles ; l’autre défend une ouverture de bout en bout, qui porte sur le corpus d’entraînement, le code de préparation et d’entraînement, les poids des modèles et leur documentation, afin de rendre l’ensemble plus auditable, reproductible et transférable. La résidence régionale du modèle ne démontre pas la réversibilité de toute la chaîne. À l’inverse, l’accès à tous ces artefacts ne prouve pas qu’une organisation saura les exploiter durablement, avec le niveau de sécurité, de performance et de disponibilité attendu. L’ouverture complète constitue un actif de souveraineté beaucoup plus fort que les seuls poids, mais l’opérabilité reste une capacité distincte à organiser et à financer.

Les limites doivent être examinées au bon périmètre. Mistral reconnaît que certains services appelés par les agents, comme la recherche web, peuvent impliquer des sous-traitants situés hors de la région choisie ; ces fonctions peuvent alors devoir être désactivées ou restreintes. Par ailleurs, les engagements d’environ cinq ans présentés comme non résiliables par anticipation concernent les European Compute Units destinées à financer de nouvelles capacités, et non l’ensemble des contrats ou des accès aux modèles de Mistral. Ces deux points suffisent néanmoins à rappeler qu’une infrastructure européenne peut réduire certaines dépendances tout en en créant d’autres, contractuelles, matérielles, logicielles ou économiques.

Pour une collectivité ou un opérateur mutualisé, il serait donc trop simple de déclarer un fournisseur souverain ou non souverain dans son ensemble. Il faut vérifier, service par service, l’origine et la licence du modèle, le lieu des traitements et des journaux, les flux des outils connectés, les droits d’emport, la possibilité de conserver une version, les engagements de capacité et le coût réel d’un remplacement.

Le financement public oriente déjà les décisions

Le guichet de cofinancement du programme Territoires d’IA de la Banque des Territoires est ouvert depuis le 22 mai 2026 pour une durée de trois ans. Il finance entre 30 % et 50 % des dépenses éligibles pour l’achat de licences ou de solutions logicielles d’IA répondant à sa définition de la souveraineté.

Le mécanisme encourage explicitement les effets d’échelle. Le financement de base est de 30 %. Il passe à 40 % lorsque la demande est mutualisée ou porte sur au moins 500 licences. Une demande mutualisée doit couvrir, en plus de son porteur, au moins trois autres bénéficiaires éligibles. Une démarche d’IA frugale peut ajouter 10 points, dans la limite de 50 %. La Banque des Territoires donne ainsi l’exemple d’une demande mutualisée assortie d’une démarche frugale, financée à 50 %.

Cette aide constitue une occasion réelle pour les collectivités et leurs opérateurs. Elle comporte aussi une direction implicite : le guichet est principalement orienté vers l’achat. Il couvre un an d’accès à une solution et peut intégrer, dans les limites prévues, son déploiement, son paramétrage et la formation à sa prise en main. Une demande ne peut porter que sur une seule solution. Les développements spécifiques et les prestations d’accompagnement qui sortent de ce périmètre ne sont pas éligibles.

Le financement ne doit donc pas choisir l’architecture à la place de la collectivité. Une licence financée à 50 % peut rester mal adaptée au besoin. Elle peut aussi créer, dès la deuxième année, un coût récurrent, une dépendance ou une charge de support insuffisamment anticipés. Le dossier économique devrait projeter au moins trois années de coût complet : licences et consommation, intégration, préparation des données, sécurité, accompagnement, maintenance, compétences internes et sortie. La subvention réduit l’effort d’amorçage ; elle ne démontre pas la soutenabilité du service.

Acheter suppose d’abord de qualifier

Dans plusieurs accompagnements récents, nous voyons des collectivités et des OPSN explorer ou qualifier, dans des contextes distincts, des solutions françaises telles que Delos, Dicte.ai, Prox.ia ou Delibia. Elles ne répondent pas aux mêmes besoins : productivité documentaire, transcription et comptes rendus, accès encadré aux modèles génératifs, recherche spécialisée ou commande publique.

Leur présence ici ne constitue ni un classement ni une recommandation générale. Tester n’est pas adopter. Une solution française n’est pas automatiquement souveraine au sens du cahier des charges de la Banque des Territoires. Une expérimentation satisfaisante dans une organisation ne préjuge pas du résultat dans une autre.

La qualification doit partir du travail à accomplir et porter sur un couple précis « solution × cas d’usage ». Quel irritant cherche-t-on à réduire ? Quelles données entrent dans le système ? Quelle erreur est inacceptable ? Qui relit et qui signe ? Le test doit ensuite examiner l’adéquation fonctionnelle, la qualité des résultats, l’hébergement, les modèles et sous-traitants, la cybersécurité, l’accessibilité, la frugalité, la conservation des traces, le coût complet, l’intégration au système d’information et la réversibilité. Il doit aussi conserver une hypothèse parfois oubliée : une procédure mieux conçue, un moteur de recherche classique ou une automatisation sans IA peuvent suffire.

Mutualiser cette qualification serait déjà un actif précieux. Des OPSN peuvent partager un protocole, des jeux de test débarrassés de données personnelles, des clauses d’achat, des questions à poser aux fournisseurs et des retours d’incident. Chaque collectivité garde sa décision et ses données ; toutes évitent de redécouvrir séparément les mêmes limites.

Construire ne signifie pas tout refaire

Le terrain fait également apparaître du « make ». Il ne s’agit généralement pas d’entraîner un grand modèle ni de reconstruire un produit complet. Des équipes apprennent à décrire leurs flux de travail, à relier des applications dans n8n, à concevoir des agents spécialisés et à encadrer leur action.

Cette montée en compétence change la place de l’acteur public. Celui-ci peut acheter un modèle ou une brique spécialisée tout en conservant la conception du processus, les règles métier, les tests, les validations humaines et les mécanismes d’arrêt. L’architecture devient hybride : certaines capacités sont achetées ou mutualisées ; la connaissance critique du service demeure maîtrisée.

Un agent capable d’enchaîner des actions demande cependant davantage de discipline qu’un assistant qui produit un texte. Il faut limiter ses droits, vérifier les entrées et les sorties, journaliser ce qu’il fait, prévoir la reprise manuelle, tester les échecs et nommer les responsables. C’est le rôle d’un harnais d’IA : l’ensemble des règles, tests, validations humaines, journaux et mécanismes d’arrêt qui encadrent un ou plusieurs modèles ou agents dans un processus réel.

Le « make » possède lui aussi ses angles morts. Un prototype n’est pas un service opéré. Sans documentation, maintenance, supervision, compétences de remplacement et budget, la maîtrise affichée peut dépendre d’une personne ou d’un assemblage fragile. La décision doit comparer ces charges à celles du « buy », et non opposer artificiellement autonomie publique et solution du marché.

Ce qui mérite réellement d’être mis en commun

Au fond, la mutualisation peut porter sur des objets très différents : une infrastructure, un contrat, une équipe, un composant n8n, un agent, une bibliothèque documentaire, un corpus de tests, des clauses, une formation, un dispositif de support ou un registre d’incidents. Tous n’appellent pas la même gouvernance.

Avant le budget, une fiche courte peut rendre le choix lisible pour une direction, une DSI, les métiers, les élus et l’opérateur mutualisé :

  1. Besoin et bénéficiaires. Quel travail doit être amélioré, pour quels agents ou usagers, et quelle option non-IA a été examinée ?
  2. Trajectoire choisie. Service mutualisé, achat, construction interne ou architecture hybride : pourquoi cette voie est-elle proportionnée ?
  3. Objet partagé. Que met-on exactement en commun : licences, exploitation, code, tests, compétences, support ou retours d’expérience ?
  4. Responsabilités. Qui tient la feuille de route, contrôle le résultat, gère les incidents et peut arrêter l’usage ?
  5. Données et dépendances. Que reste-t-il local ? Quels modèles, hébergeurs, opérateurs d’inférence, éditeurs d’origine, sous-traitants et outils connectés conditionnent le service ? La version du modèle peut-elle être conservée, auditée et remplacée ?
  6. Preuve d’acceptation. Quel résultat observable autorise le passage de l’essai à l’usage, et quel écart impose une correction ou un arrêt ?
  7. Coût complet et sortie. Que coûtera le service après l’aide ou l’expérimentation, comment sera-t-il maintenu et comment en sortir sans perdre les données, les configurations et la capacité d’agir ?

Une mutualisation utile ne cherche pas nécessairement à tout centraliser. Elle place au bon niveau ce qui gagne à être partagé et protège ce qui doit rester sous responsabilité locale. Elle peut même conduire à renoncer à une plateforme lorsque l’usage est trop rare, les données trop sensibles ou l’exploitation trop fragile.

Le choix décisif n’est donc pas entre « faire » et « acheter ». Il consiste à déterminer ce que la puissance publique doit savoir faire elle-même, ce qu’elle peut confier, ce qu’elle a intérêt à partager et ce qu’elle doit pouvoir reprendre. C’est à cette condition que la mutualisation produit autre chose qu’une économie temporaire : une capacité publique durable à choisir, apprendre et agir avec l’IA.

Sources

Comment cet article a été produit

Cet article a été préparé avec l’appui d’un harnais d’IA pour la recherche documentaire, la confrontation des hypothèses, la rédaction et les contrôles. Pascal Chevallot conserve l’angle, vérifie les sources, arbitre le texte et assume seul la décision de publier et la responsabilité de l’article.

Toutes nos actualités