IA dans le cloud ou en local : comment choisir en 2026

Avec une IA cloud, les données sont transmises vers l’infrastructure d’un prestataire pour être traitées. Les offres professionnelles peuvent ajouter le chiffrement, des contrôles de conservation, des engagements contractuels et des options excluant l’entraînement sur les données client. Ces mécanismes réduisent le risque, mais l’information franchit toujours le périmètre de l’organisation.

Avec une IA locale, les prompts et les fichiers peuvent rester dans le réseau de l’entreprise. Une configuration correctement isolée peut même fonctionner sans connexion externe. Cette architecture est adaptée aux informations couvertes par le secret professionnel, aux dossiers de santé, aux données financières et aux documents industriels confidentiels.

Le local ne constitue pas une garantie automatique. Un serveur mal configuré, un modèle téléchargé depuis une source douteuse, des journaux trop détaillés ou des droits d’accès excessifs peuvent créer une faille. Il faut donc prévoir l’authentification, le chiffrement des disques, les mises à jour, la journalisation maîtrisée et une politique de sauvegarde.

Pour les données sensibles, le critère déterminant n’est donc pas seulement la mention « entreprise » d’un service cloud. Il faut vérifier la région d’hébergement, la conservation des requêtes, l’usage pour l’entraînement, les sous-traitants et les procédures de suppression.

Le cloud transforme l’IA en dépense opérationnelle. Une API facture généralement les tokens entrants et sortants, tandis qu’un assistant professionnel peut fonctionner avec un abonnement par utilisateur. Cette structure convient aux volumes variables, car l’entreprise ne paie pas une capacité matérielle inutilisée.

Le coût augmente toutefois avec le nombre d’utilisateurs, la longueur des contextes, les appels d’outils et les traitements automatisés. Une charge de 10 millions de tokens par jour facturée 5 dollars par million représente 50 dollars par jour, soit environ 18 000 dollars par an avant les éventuels coûts annexes.

Le local demande un investissement initial : GPU, mémoire, stockage, alimentation, refroidissement et parfois serveur dédié. Une configuration de travail capable d’exécuter des modèles locaux peut coûter plusieurs milliers de dollars. À l’échelle entreprise, un GPU NVIDIA H100 est souvent cité entre 25 000 et 30 000 dollars à l’achat. La consommation électrique, l’administration système et le remplacement du matériel doivent entrer dans le calcul.

Le seuil de rentabilité dépend du taux d’utilisation. Un GPU loué autour de 2 dollars par heure peut devenir plus coûteux qu’un GPU acheté après plusieurs milliers d’heures, mais cet équilibre change selon le prix réel du matériel, l’électricité, la maintenance et le taux d’occupation. Pour une petite équipe ou un volume irrégulier, le cloud est souvent plus rationnel. Pour une charge stable et élevée, le local mérite une modélisation sur trois ans.

Les services cloud donnent accès aux modèles propriétaires les plus avancés sans achat de GPU. Ils peuvent répartir la charge sur plusieurs accélérateurs et absorber des pics d’activité. Cette capacité est utile pour le raisonnement complexe, l’analyse de longs documents, la génération multimodale et les applications qui doivent servir beaucoup d’utilisateurs simultanément.

L’IA locale peut être plus rapide sur des tâches courtes lorsque le modèle tient en mémoire et que les données se trouvent déjà sur la machine. Elle évite le temps de transmission réseau et offre une latence stable dans un environnement bien dimensionné. En revanche, un modèle local plus petit peut être moins précis ou moins polyvalent qu’un modèle cloud de pointe.

La performance ne se mesure pas uniquement en tokens par seconde. Il faut aussi évaluer la qualité des réponses, le taux d’erreur, le temps jusqu’au premier token, la disponibilité, la capacité à traiter plusieurs requêtes et la stabilité des résultats. Un modèle rapide mais nécessitant de nombreuses vérifications humaines peut coûter davantage qu’un modèle plus lent et plus fiable.

Le benchmark pertinent doit utiliser vos propres prompts et documents. Testez au minimum la qualité, la latence p95, le débit simultané, la consommation mémoire et le coût par tâche. Les chiffres publiés par les fournisseurs ne suffisent pas à prédire le résultat sur votre cas d’usage.

Le cloud est le choix le plus simple lorsque le projet doit démarrer rapidement, que la demande varie fortement ou que l’équipe ne souhaite pas administrer des GPU. Il convient aussi aux prototypes, aux assistants généralistes et aux applications qui bénéficient des modèles les plus récents.

Le local devient prioritaire lorsque les données ne doivent pas quitter l’organisation, que la connexion est limitée ou que le volume de calcul reste élevé et stable. Il peut également réduire la dépendance à un fournisseur, mais il faut accepter la responsabilité de l’infrastructure et des mises à jour.

L’architecture hybride combine les deux approches. Un routeur peut envoyer les documents confidentiels vers un modèle local et les requêtes générales vers une API cloud. Une autre stratégie consiste à anonymiser les données avant tout appel externe, puis à conserver les bases documentaires et les journaux dans le réseau interne.

• ▹Choisissez le cloud pour un prototype, une demande fluctuante ou l’accès aux modèles les plus puissants.
• ▹Choisissez le local pour la confidentialité stricte, le fonctionnement hors connexion ou une charge régulière.
• ▹Choisissez l’hybride lorsque les niveaux de sensibilité et les besoins de performance varient selon les tâches.
• ▹Ajoutez des quotas, une limite budgétaire et une journalisation des coûts pour le cloud.
• ▹Ajoutez un contrôle d’accès, des mises à jour et une supervision GPU pour le local.

Avant de décider, classez les données en niveaux de sensibilité, mesurez le volume mensuel de tokens, estimez le nombre de requêtes simultanées et comparez le coût total sur 36 mois. Une démonstration de quelques jours avec vos propres documents vaut mieux qu’un choix fondé uniquement sur le prix d’une API ou sur la puissance théorique d’un GPU.

Commencez par inventorier les usages : chatbot interne, résumé, génération de code, extraction de données, recherche documentaire ou traitement d’images. Chaque tâche n’a pas les mêmes exigences de qualité, de latence et de confidentialité.

Ensuite, classez les données. Les informations publiques peuvent être traitées dans le cloud avec des contrôles standards. Les données personnelles, contractuelles ou stratégiques exigent une analyse plus stricte. Les dossiers soumis à une obligation de souveraineté peuvent imposer une architecture locale ou un hébergement cloud spécifiquement encadré.

Mesurez ensuite la charge réelle : utilisateurs actifs, requêtes par jour, tokens moyens, longueur des documents, pics horaires et taux de simultanéité. Cette étape évite de comparer un abonnement théorique à un serveur surdimensionné.

• ▹Étape 1 : identifier les tâches et le niveau de qualité requis.
• ▹Étape 2 : classer les données et les contraintes réglementaires.
• ▹Étape 3 : mesurer volume, latence et simultanéité.
• ▹Étape 4 : réaliser un pilote cloud et un pilote local sur les mêmes prompts.
• ▹Étape 5 : choisir selon le coût total, le risque et la réversibilité.

La décision finale doit inclure un scénario de sortie. Exportez les prompts, les évaluations, les configurations et les données afin de pouvoir changer de modèle. Pour le cloud, prévoyez des plafonds de dépense et une solution de secours. Pour le local, prévoyez le remplacement du matériel, les mises à jour de sécurité et une capacité de support.

En pratique, le choix le plus équilibré est souvent progressif : cloud pour valider la valeur métier, local pour les flux sensibles ou suffisamment volumineux, puis architecture hybride lorsque les usages se diversifient.