IA locale ou IA cloud : sur quoi se décide le choix
Exécuter un modèle sur son propre matériel ou l'appeler via un service en ligne sont deux options défendables. Le choix se décide sur la nature des données traitées, la charge réelle, les compétences disponibles en interne et la réversibilité souhaitée — pas sur un principe général.
De quoi parle-t-on
IA locale : le modèle s'exécute sur du matériel que vous contrôlez — un serveur dans vos locaux, ou une machine dédiée chez un hébergeur. Les données traitées ne sortent pas de ce périmètre.
IA cloud : vous appelez un modèle hébergé par un fournisseur. Votre application envoie la requête, reçoit la réponse, et ne gère aucune infrastructure.
Le débat est souvent présenté comme un choix idéologique entre souveraineté et facilité. En pratique, quatre critères concrets suffisent à trancher, et ils ne pointent pas toujours dans la même direction.
Les quatre critères qui décident
1. La nature des données
C'est le critère dominant, et parfois le seul qui compte. Des données couvertes par un secret professionnel — dossiers d'avocats, données de santé, dossiers de clients d'une fiduciaire — orientent vers un traitement local ou une instance dédiée. Des données déjà publiques ou anodines ne justifient pas cette contrainte.
2. La charge réelle
Le cloud se paie à l'usage : quelques dizaines de traitements par jour coûtent peu. Le local se paie d'avance : le matériel coûte la même chose qu'il tourne une heure ou vingt-quatre. Le point de bascule dépend du volume et du modèle employé — il se calcule, il ne se devine pas. Une règle utile : tant que l'usage n'est pas stabilisé, le cloud évite d'acheter du matériel pour un besoin mal connu.
3. Les compétences disponibles
Un serveur d'inférence local doit être surveillé, mis à jour, sauvegardé, et redémarré quand il tombe. Sans personne pour s'en charger — en interne ou par contrat — le local devient un point de fragilité plutôt qu'un gage de contrôle.
4. La réversibilité souhaitée
Un fournisseur peut changer ses tarifs, ses conditions, ou retirer un modèle. Le local protège de cela au prix de l'exploitation. Une position intermédiaire consiste à isoler dès le départ la couche qui appelle le modèle, afin de pouvoir en changer sans réécrire le reste du système. C'est le choix le plus prudent quand on ne sait pas encore.
Tableau comparatif
| Critère | IA locale | IA cloud |
|---|---|---|
| Sortie des données | Aucune hors du périmètre | Oui, vers le fournisseur |
| Structure de coût | Investissement initial, coût d'usage faible | Pas d'investissement, coût par appel |
| Mise en service | Jours à semaines | Heures |
| Puissance accessible | Limitée par le matériel | Les plus gros modèles disponibles |
| Exploitation | À votre charge | À la charge du fournisseur |
| Montée en charge | Achat de matériel | Immédiate |
| Dépendance fournisseur | Faible | Réelle |
| Fonctionnement hors ligne | Possible | Impossible |
Une régie immobilière veut classer automatiquement les demandes d'intervention reçues par courriel et en extraire l'immeuble concerné. Le volume est de quelques dizaines par jour. Les données contiennent des noms de locataires et des adresses, mais rien de couvert par un secret professionnel.
Ici, un service cloud sous contrat professionnel est un point de départ défendable : le volume ne justifie pas un investissement matériel, et la mise en service prend quelques heures. La précaution utile consiste à isoler l'appel au modèle derrière une interface interne, de sorte qu'un passage vers une solution locale reste possible si le volume augmente ou si un client l'exige.
L'approche mixte
Rien n'oblige à choisir une fois pour toutes. Une répartition fréquente et raisonnable :
- En local : ce qui touche aux documents clients — extraction, classement, indexation pour RAG. Ce sont aussi des tâches délimitées, où un modèle plus petit suffit.
- En cloud : ce qui demande du raisonnement sur des contenus non sensibles — reformulation, synthèse, aide à la rédaction.
Cette séparation suppose une règle explicite sur ce qui a le droit de sortir. Sans cette règle écrite, la frontière se déplace au fil des ajouts, et généralement dans le mauvais sens.
Les erreurs de raisonnement fréquentes
- Croire que local égale sécurisé. Un serveur exposé et mal tenu est plus risqué qu'un service professionnel correctement contractualisé. La sécurité est une pratique, pas un emplacement.
- Sous-estimer l'exploitation. Le coût d'un serveur ne s'arrête pas à son prix d'achat : il inclut le temps de quelqu'un, chaque mois, pendant des années.
- Surestimer le besoin de puissance. Extraire cinq champs d'une facture ne réclame pas le plus grand modèle du marché. La tâche dicte la taille, pas l'inverse.
- Traiter la question comme définitive. C'est une décision d'architecture révisable, à condition de l'avoir conçue pour l'être.
Questions fréquentes
L'IA locale revient-elle moins cher ?
Elle déplace le coût : moins de coût à l'usage, mais un investissement matériel et du temps d'exploitation. Elle devient intéressante à charge soutenue et régulière.
Peut-on commencer en cloud puis passer en local ?
Oui, à condition d'avoir isolé dès le départ la couche qui appelle le modèle, pour pouvoir en changer sans réécrire le reste.
Le cloud est-il exclu pour des données sensibles ?
Non. Ce qui compte est le contrat, la localisation du traitement, la politique de conservation et la non-réutilisation des données. Ces points se vérifient et s'écrivent.
Articles liés
Sources
- Centre national pour la cybersécurité (NCSC) — https://www.ncsc.admin.ch/ncsc/fr/home.html
- Préposé fédéral à la protection des données et à la transparence (PFPDT) — https://www.edoeb.admin.ch/fr