Trois charges d’IA, trois réponses différentes
Imaginons une entreprise qui veut classer ses courriels entrants, interroger une documentation interne et produire occasionnellement une étude complexe. Réunir ces besoins sous l’étiquette « intelligence artificielle » masque leurs différences.
Le classement répétitif peut convenir à un petit modèle spécialisé, exécuté sur CPU et évalué sur les messages de l’entreprise. La recherche documentaire contient peut-être des informations qui ne doivent pas quitter le système d’information ; une exécution locale, ou un hébergement privé maîtrisé, devient alors intéressante. L’étude complexe, lancée quelques fois par mois, peut justifier l’appel à un modèle distant plus puissant plutôt que l’achat d’une machine largement inactive.
Cette répartition n’a rien d’un compromis par défaut. Elle évite de payer une infrastructure surdimensionnée pour les pointes tout en conservant près des données les traitements stables et sensibles.
Taille du modèle et lieu d’exécution sont deux décisions distinctes
Un petit modèle peut tourner localement ou dans le cloud ; un modèle spécialisé n’est pas nécessairement petit. Ces caractéristiques doivent être examinées séparément. Une PME n’a pas toujours besoin d’un système capable de rédiger, traduire, raisonner et programmer dans la même requête. Extraction, classement, détection, recherche sémantique ou routage relèvent souvent de modèles plus étroits.
Le billet de Liquid AI sur ses encodeurs compacts présente des résultats de traitement de séquences longues sur CPU. Le billet consacré à Nunchaku dans Diffusers décrit comment la quantification à quatre bits réduit, dans les cas présentés, la mémoire nécessaire à l’inférence d’images. Ces exemples ne valent pas benchmark universel ; ils illustrent une direction d’architecture : avant d’acheter plus de calcul, réduire le problème.
Un petit modèle n’est toutefois pas « suffisant » par nature. Il doit être confronté aux données réelles, aux accents, aux documents incomplets et aux erreurs coûteuses du métier. La bonne mesure n’est pas sa performance moyenne sur un classement public, mais son comportement sur les cas que l’entreprise ne peut pas se permettre de rater.
Le coût du local se trouve souvent hors de la facture
L’inférence sur site évite la facturation au token pour la charge concernée. En échange, elle immobilise du matériel. Il faut ajouter l’électricité, le refroidissement, les mises à jour, la supervision, les pannes et le temps de la personne qui maintient l’ensemble. Un GPU utilisé deux heures par semaine peut donner une impression d’indépendance tout en constituant un investissement médiocre.
Le cloud cache d’autres coûts : consommation difficile à attribuer, hausse tarifaire, dépendance à une API, migration des données et réécriture d’une intégration propriétaire. Une facturation à l’usage peut convenir à un besoin irrégulier, mais il faut vérifier les abonnements, engagements minimaux et ressources réservées qui restent facturés même sans requête.
Comparer un tarif par requête au prix d’une carte graphique ne mène donc nulle part. Il faut calculer le coût d’une tâche utile sur une période crédible, avec le taux d’utilisation, l’exploitation et le scénario de remplacement.
La confidentialité ne se déduit pas de la prise électrique
Faire tourner un modèle localement réduit certains transferts de données. Cela ne prouve pas que rien ne sort de la machine. Une application peut envoyer de la télémétrie, charger des composants distants ou dépendre d’un compte fournisseur. À l’inverse, un service externe peut offrir des garanties contractuelles et techniques sérieuses sur la conservation, le chiffrement et la localisation.
Il faut observer les flux au lieu de se fier à l’étiquette. Où part la requête ? Quels journaux sont conservés ? Qui détient les clés ? Peut-on désactiver les communications non nécessaires ? Dans quel format récupère-t-on le contexte et les données si l’on change de solution ?
Le paquet européen présenté le 3 juin 2026 associe le CADA au développement des capacités cloud et IA et à leur évaluation. Cette ambition ne dispense pas chaque organisation de vérifier les dépendances de l’offre qu’elle envisage.
Et l’énergie ? Pas de verdict sans mesure
L’Agence internationale de l’énergie documente la hausse de la demande électrique associée aux centres de données et à l’IA. En déduire que le local serait sobre, ou que le cloud serait nécessairement plus efficace, serait hasardeux.
Le bilan dépend du matériel déjà présent, de sa durée de vie, de son utilisation, du modèle choisi, de l’intensité carbone de l’électricité et de l’efficacité du centre distant. Mutualiser une infrastructure très sollicitée peut être préférable à multiplier des accélérateurs presque inactifs. Réutiliser une machine existante pour un modèle compact peut, dans un autre cas, éviter des appels distants et un nouvel abonnement.
La première économie consiste à ne pas lancer un grand modèle lorsqu’un classifieur, une règle métier ou une recherche classique suffit.
La réversibilité tranche les cas difficiles
Lorsqu’aucune option ne s’impose, un test simple départage les architectures : combien de temps faudrait-il pour déplacer la charge ? Une solution locale dont personne ne sait reconstruire l’environnement est fragile. Un service cloud dont les données et les prompts ne sont pas exportables l’est tout autant.
Une architecture maîtrisée conserve les jeux d’évaluation, documente les dépendances, plafonne les dépenses distantes et prévoit un fonctionnement dégradé. Elle peut router certaines requêtes vers un petit modèle local et réserver le modèle externe aux cas qui le justifient. Elle accepte surtout d’être révisée lorsque les volumes, les tarifs ou les modèles changent.
La souveraineté ne consiste pas à posséder chaque machine. Elle commence lorsque l’entreprise peut choisir où tourne son intelligence artificielle — puis changer d’avis sans devoir reconstruire tout son système.