Quand les organisations parlent d'IA locale, elles pensent souvent à un sujet de souveraineté ou d'idéologie technologique. C'est une lecture trop étroite. Le local-first est d'abord une décision d'architecture motivée par des contraintes opérationnelles réelles : confidentialité, conformité, intégration avec des systèmes existants, ou tout simplement maîtrise d'un système critique.
Les quatre sens du mot « local » en entreprise
Avant d'aller plus loin, il est important de clarifier ce que « local » signifie dans ce contexte, car le terme recouvre des réalités très différentes :
- On-premise strict : tous les composants (modèle, indexation, retrieval) tournent sur l'infrastructure interne de l'entreprise. Aucun flux ne sort vers un prestataire externe. C'est le cas le plus contraignant, typiquement requis pour les données classifiées ou les environnements très isolés.
- Cloud privé ou VPC : l'infrastructure est dans le cloud, mais dans un environnement isolé, dédié à l'organisation. Les données ne transitent pas par des infrastructures partagées. C'est souvent l'approche des grands groupes avec des accords cloud souverains.
- Architecture hybride : le modèle de génération peut être cloud (pour des usages non-sensibles), mais la couche de contexte – les documents, l'index, le retrieval – reste locale. C'est l'approche la plus pragmatique pour beaucoup d'organisations.
- Open-source self-hosted : des modèles open-source (Mistral, Llama, Phi-3) déployés sur infrastructure propre. Moins performants que les modèles fermés les plus récents, mais suffisants pour beaucoup d'usages internes.
Quand le local est requis, pas juste préféré
Pour certaines organisations, le local n'est pas une option parmi d'autres – c'est une exigence non-négociable. Quatre situations le rendent impératif :
- RGPD et données à caractère personnel : dès que des données personnelles sont ingérées dans le corpus (dossiers clients, données RH, informations médicales), le transfert vers un modèle cloud tiers doit passer par une analyse juridique rigoureuse. Pour éviter cette complexité, beaucoup d'organisations choisissent l'architecture locale.
- Secret d'affaires et propriété intellectuelle : formules de produits, stratégies commerciales, bases de données clients – certaines informations ne doivent simplement pas sortir de l'infrastructure. La promesse contractuelle d'un prestataire cloud ne suffit pas à convaincre tous les boards.
- Environnements réglementés : secteurs bancaire (DORA), santé (HDS), défense, ou secteurs soumis à audit régulier : la question « où vont les données ? » ne peut pas rester floue.
- Continuité opérationnelle : un système IA critique dont le fonctionnement dépend d'une API cloud peut être compromis par une panne de connectivité. Une architecture locale assure la résilience opérationnelle.
Le point souvent oublié : la couche de contexte est plus sensible que le modèle
Dans le débat local vs cloud, l'attention porte souvent sur le modèle. C'est une erreur. Le modèle GPT-4o ou Claude 3 est public – il est utilisé par des millions d'autres organisations. Ce qui est spécifique à votre organisation, ce sont vos données : vos procédures internes, vos bases clients, vos documents stratégiques, vos corpus métier.
C'est la couche de contexte qui est sensible, pas le modèle. Cela a une conséquence architecturale importante : même si vous utilisez un modèle cloud, la couche de retrieval – l'indexation, la recherche, la préparation du contexte – doit rester sur une infrastructure que vous contrôlez. C'est l'approche hybride, et c'est souvent la plus équilibrée.
Les trois arbitrages principaux à faire
Le choix d'une architecture locale implique des compromis réels :
- Performance vs souveraineté : les modèles cloud les plus récents sont encore plus performants que la plupart des modèles open-source déployables en local. Selon l'usage, cet écart peut ou non être acceptable.
- Coût d'infrastructure vs coût d'usage : un déploiement local a un coût fixe (serveurs, GPU, maintenance). Un modèle cloud a un coût variable à l'usage. Les arbitrages financiers dépendent du volume d'utilisation prévu.
- Autonomie vs facilité de mise à jour : un modèle auto-hébergé ne se met pas à jour automatiquement. Ce qui est un avantage en termes de stabilité peut devenir un inconvénient si des mises à jour substantielles sont disponibles.
Un cadre de décision en quatre questions
Avant de décider d'une architecture, quatre questions permettent de cadrer le choix :
- Quelles catégories de données vont alimenter le système ? (Personnelles ? Classifiées ? Stratégiques ?)
- Qui peut voir ces données ? (Uniquement l'équipe interne ? Des prestataires ? Des partenaires ?)
- Quelles sont les exigences réglementaires explicites dans votre secteur ?
- Quel est le volume d'utilisation prévu ? (Cela oriente le modèle économique cloud vs local.)
Conclusion
Le local-first n'est pas une posture. C'est une décision d'architecture qui doit être fondée sur des contraintes réelles et des arbitrages conscients. Pour beaucoup d'organisations, le meilleur choix n'est ni entièrement local ni entièrement cloud – c'est une architecture hybride où la couche de contexte (la plus sensible) reste contrôlée, et où le modèle de génération est choisi selon le niveau de sensibilité de chaque usage.