Ollama et Drupal : IA souveraine

L'intelligence artificielle s'invite dans les sites Drupal : génération de résumés, suggestions de balises, assistance à la rédaction, recherche sémantique, classification de contenu. La voie la plus rapide passe par une API externe (un appel réseau vers un fournisseur, une réponse en quelques secondes). C'est efficace, mais cela soulève une question que tout décideur finit par se poser : où partent les données soumises au modèle ? Pour une administration, un acteur de la santé ou une organisation soumise à des contraintes réglementaires, la réponse n'est pas anecdotique.

Il existe une alternative crédible : héberger le modèle vous-même, sur votre propre infrastructure, et n'envoyer aucune donnée à l'extérieur. Ollama est l'outil qui rend cette approche accessible. Cet article explique pourquoi la souveraineté des données compte, comment fonctionne Ollama, quels modèles il permet d'exploiter, comment le brancher à Drupal via le module AI et où se situent les limites du local par rapport à une API externe. L'objectif est de vous donner les éléments factuels pour décider, pas de vendre une approche unique.

Pourquoi la souveraineté des données compte

La souveraineté des données désigne le contrôle effectif sur l'endroit où vos données sont traitées, stockées et exposées. Dès qu'un contenu transite par une API d'IA hébergée hors de votre périmètre, vous perdez une partie de ce contrôle. Plusieurs facteurs en font un sujet de direction, pas seulement de technique.

Le cadre réglementaire. Le RGPD encadre le traitement des données personnelles et leur transfert hors de l'Union européenne. Envoyer des contenus contenant des données personnelles vers un fournisseur d'IA situé dans un pays tiers implique de vérifier la base légale, les garanties contractuelles et la localisation réelle du traitement. Pour certaines organisations, cette vérification est lourde, pour d'autres elle est tout simplement rédhibitoire.

Le secteur public. Les administrations, collectivités et établissements publics sont souvent soumis à des doctrines de type "cloud au centre" ou à des exigences de souveraineté qui restreignent l'usage de services hébergés à l'étranger. Un modèle auto-hébergé sur une infrastructure maîtrisée répond directement à ces contraintes.

Les données sensibles. Dossiers médicaux, données RH, contrats, propriété intellectuelle, échanges juridiques : certains contenus ne devraient jamais quitter l'organisation. Le risque n'est pas seulement réglementaire, il est aussi concurrentiel et réputationnel. Garder le traitement en local supprime la question à la source.

La traçabilité. Avec une infrastructure que vous contrôlez, vous savez précisément quels journaux existent, qui y accède et combien de temps les données sont conservées. Cette visibilité est difficile à obtenir avec un service tiers, où vous dépendez des engagements contractuels du fournisseur.

La souveraineté n'est pas un absolu : c'est un curseur que chaque organisation positionne selon ses enjeux. Pour beaucoup de cas d'usage grand public, une API externe reste parfaitement appropriée. Mais quand la sensibilité monte, le modèle auto-hébergé devient l'option par défaut.

Ollama : ce que c'est et comment ça fonctionne

Ollama est un outil open source qui simplifie l'exécution de modèles de langage (LLM) en local, sur votre propre machine ou serveur. Là où le déploiement manuel d'un modèle demandait historiquement une expertise en infrastructure GPU et en frameworks de machine learning, Ollama réduit l'opération à quelques commandes.

Le principe est simple. Vous installez Ollama sur un serveur, vous récupérez un modèle depuis sa bibliothèque (une seule commande de type ollama pull), et l'outil expose une API HTTP locale. Cette API parle un langage proche de celui des fournisseurs commerciaux : votre application envoie un prompt, Ollama exécute le modèle sur votre matériel et renvoie la réponse. Aucune donnée ne sort de votre réseau.

Concrètement, Ollama gère pour vous le téléchargement des poids du modèle (les open weights), leur chargement en mémoire, la quantification (une compression qui réduit l'empreinte mémoire au prix d'une légère perte de précision) et l'exposition d'une interface stable. Il tourne sur Linux, macOS et Windows, et s'intègre naturellement dans un conteneur Docker, ce qui facilite son déploiement aux côtés d'une stack Drupal existante.

Le point clé pour un décideur : Ollama transforme un modèle de langage en service interne, comparable à une base de données ou à un cache. Vous l'hébergez, vous le dimensionnez et vous le maintenez comme n'importe quel composant de votre infrastructure.

Les modèles supportés

Ollama donne accès à un catalogue de modèles open weights, c'est-à-dire des modèles dont les poids sont publiquement distribués et exécutables sur votre matériel. Les familles les plus utilisées couvrent un large éventail de besoins.

LLaMA (Meta). L'une des familles open weights les plus répandues, déclinée en plusieurs tailles. Les versions de taille intermédiaire offrent un bon compromis entre qualité de génération et exigences matérielles, ce qui en fait un choix fréquent pour des tâches de rédaction et de synthèse.

Mistral. Développée par une société française, cette famille de modèles est appréciée pour son efficacité : de bonnes performances pour une empreinte mémoire raisonnable. Les variantes Mixtral, basées sur une architecture de type "mixture of experts", offrent davantage de capacité tout en restant exploitables sur des serveurs bien dimensionnés.

Autres modèles. La bibliothèque inclut de nombreuses autres familles open weights, dont des modèles spécialisés (génération de code, embeddings pour la recherche sémantique, modèles multilingues). Les modèles d'embeddings sont particulièrement utiles dans Drupal pour alimenter une recherche vectorielle sans dépendre d'un service externe.

Le choix du modèle dépend de trois variables : la tâche visée, la qualité attendue et le matériel disponible. Un petit modèle suffit pour de la classification ou de l'étiquetage automatique. Une génération de texte de qualité éditoriale demandera un modèle plus grand, donc plus de ressources. C'est un arbitrage à poser projet par projet, et c'est l'un des points où un accompagnement vaut son pesant.

Configuration avec le module Drupal AI

L'écosystème Drupal dispose d'un module AI (parfois appelé "AI core") qui fournit une couche d'abstraction au-dessus des différents fournisseurs d'IA. Sa philosophie est de découpler la logique métier du fournisseur sous-jacent : vous écrivez votre fonctionnalité une fois, et vous branchez le fournisseur de votre choix derrière.

Pour le local, le module s'appuie sur un sous-module fournisseur dédié à Ollama. La mise en route suit une logique éprouvée. Vous installez Ollama et téléchargez le modèle souhaité sur votre serveur. Vous installez le module AI et son provider Ollama via Composer. Vous configurez ensuite, dans l'interface d'administration Drupal, l'URL de l'API Ollama (typiquement une adresse locale ou interne) et vous sélectionnez le modèle à utiliser pour chaque type d'opération (chat, complétion, embeddings).

À partir de là, les autres briques de l'écosystème AI de Drupal peuvent consommer ce fournisseur : assistants de rédaction dans l'éditeur, génération automatique de métadonnées, recherche augmentée, modération de contenu. Le contenu ne quitte jamais votre infrastructure, puisque l'appel se fait vers votre instance Ollama et non vers un service distant.

Cette architecture présente un avantage stratégique : vous n'êtes pas verrouillé. Si demain vous décidez qu'une API externe convient mieux à un cas d'usage donné, vous changez le fournisseur dans la configuration sans réécrire votre code. L'inverse est tout aussi vrai. Cette flexibilité est précisément ce qui rend l'investigation du local peu risquée : vous pouvez tester sans vous engager définitivement. Pour aller plus loin sur les briques disponibles, notre page dédiée à l'intégration de l'IA dans Drupal détaille les modules et les usages les plus courants.

Performance et limitations du local

L'auto-hébergement a un coût technique qu'il faut nommer clairement pour décider en connaissance de cause.

Le matériel. Un modèle de langage performant tourne idéalement sur un GPU. Sur CPU seul, l'exécution reste possible mais la latence augmente sensiblement, surtout pour les modèles de grande taille. Le dimensionnement du serveur (mémoire, GPU, stockage pour les poids) est donc une décision structurante, à poser dès le départ.

La latence et le débit. Une API commerciale mutualise une infrastructure massive et optimisée. Votre serveur local, lui, traite les requêtes avec les ressources que vous lui avez allouées. Pour un usage ponctuel ou un trafic modéré, c'est très bien. Pour des centaines de requêtes simultanées, il faut dimensionner en conséquence, ce qui a un impact sur l'infrastructure.

La qualité. Les meilleurs modèles open weights ont beaucoup progressé et couvrent de plus en plus de cas d'usage avec un niveau satisfaisant. Sur les tâches les plus exigeantes, un écart peut subsister avec les modèles propriétaires les plus avancés. Cet écart se réduit régulièrement, mais il mérite d'être évalué sur vos cas réels plutôt que supposé.

L'exploitation. Un modèle auto-hébergé est un composant d'infrastructure à part entière : mises à jour, surveillance, sauvegardes, sécurité. C'est précisément le terrain de la maintenance Drupal, qui couvre l'hébergement et l'infrastructure des modèles self-hosted au même titre que le reste de la stack. Sans ce suivi, un service local risque de devenir une dette technique silencieuse.

Ces limitations ne disqualifient pas le local : elles le cadrent. Bien dimensionné et bien maintenu, un déploiement Ollama répond à une large gamme de besoins de manière fiable.

Cas d'usage : local versus API externe

Le bon réflexe n'est pas de choisir un camp, mais d'affecter chaque cas d'usage à l'option la plus adaptée.

Plutôt en local. Tout traitement de données sensibles ou personnelles, les projets soumis à des exigences de souveraineté (secteur public, santé, défense), les tâches à fort volume où la prévisibilité des coûts d'infrastructure prime, et les usages internes où la donnée ne doit pas sortir : classification de documents confidentiels, recherche sémantique sur une base interne, assistance à la rédaction sur des contenus non publiés.

Plutôt en API externe. Les cas d'usage grand public sans donnée sensible, les besoins ponctuels où monter une infrastructure dédiée n'aurait pas de sens, les tâches qui exigent la toute dernière génération de modèles, et les projets en phase de prototypage rapide où la priorité est de valider l'idée avant d'investir dans l'hébergement.

Approche hybride. Rien n'interdit de combiner les deux. Le module AI de Drupal permet de router chaque opération vers le fournisseur approprié : le local pour les données sensibles, l'API externe pour le reste. Cette granularité est souvent la réponse la plus pragmatique pour une organisation qui veut à la fois protéger ses données critiques et bénéficier du meilleur de chaque option.

La décision se construit sur trois questions : quelle est la sensibilité des données traitées, quel est le volume attendu et quel niveau de qualité le cas d'usage exige-t-il ? Les réponses dessinent naturellement la frontière entre local et externe.

Vous évaluez l'IA souveraine pour votre site Drupal et vous voulez savoir si le local est adapté à vos cas d'usage ? Parlons de votre projet : nous posons le diagnostic, le dimensionnement et le plan d'intégration ensemble.