Un serveur sous un bureau n’est pas un talisman de souveraineté. Un abonnement cloud n’est pas davantage une stratégie. Entre les deux, les PME doivent prendre une décision moins spectaculaire et plus difficile : placer chaque traitement là où ses contraintes seront le mieux tenues.
La question « IA locale ou cloud ? » est donc mal posée lorsqu’elle arrive trop tôt. Il faut d’abord savoir ce que l’on traite, à quelle fréquence, avec quelle exigence de qualité et ce que coûterait une erreur. Le lieu d’exécution vient ensuite.
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.
Les petits modèles changent davantage l’équation que le lieu
L’industrie de l’IA entretient une fascination pour les modèles généralistes et leur nombre de paramètres. Or 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.
Les travaux techniques sur les encodeurs compacts montrent que des séquences longues peuvent être traitées rapidement sur CPU. La quantification à quatre bits réduit, dans certains cas documenté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. Son avantage reste décisif pour un besoin irrégulier : la ressource disparaît de la facture lorsqu’elle n’est plus sollicitée, à condition de surveiller réellement les usages.
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 ?
La proposition européenne CADA cherche précisément à structurer l’offre de cloud et d’IA en Europe. Elle peut améliorer la transparence et la capacité disponible. Elle ne dispense pas chaque organisation de vérifier ses propres dépendances.
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.