Depuis l’ouverture des modèles de langage à des licences permissives, une question revient dans les PME : faut-il consommer l’IA générative comme un service en ligne, facturé à l’usage, ou faire tourner un modèle sur ses propres machines ? Le débat est souvent tranché par des arguments de posture — « le cloud coûte cher », « le local n’est pas au niveau ». La réalité tient à trois paramètres mesurables : ce que le modèle exige matériellement, ce que le service facture réellement, et surtout la nature des données qu’on lui confie.
Ce que « faire tourner un modèle » demande vraiment
Le premier facteur limitant n’est pas la puissance de calcul, mais la mémoire vidéo (VRAM) du processeur graphique. Un modèle doit être entièrement chargé en mémoire pour être exploité à vitesse correcte, et l’arithmétique est simple : il faut compter le nombre de paramètres multiplié par le nombre d’octets utilisés pour coder chacun d’eux.
En précision native 16 bits, chaque paramètre occupe 2 octets : un modèle de 7 milliards de paramètres réclame donc environ 14 Go, auxquels s’ajoute la mémoire nécessaire au contexte. C’est déjà hors de portée d’une carte grand public d’entrée de gamme. La quantification change la donne : en réduisant la précision des poids à 8 puis 4 bits, on ramène ce même modèle à environ 7 Go, puis 4 Go — une carte de 8 Go suffit alors, au prix d’une dégradation généralement modeste sur les tâches courantes de rédaction ou de synthèse.
Le calcul se transpose aux tailles supérieures : un modèle de 70 milliards de paramètres demande de l’ordre de 40 Go en 4 bits, soit une carte professionnelle ou deux cartes assemblées. C’est le point de bascule budgétaire : en dessous, un poste de travail bien doté suffit ; au-dessus, on entre dans l’investissement serveur, avec ses contraintes d’alimentation, de refroidissement et de bruit que l’on anticipe rarement.
Deuxième paramètre, la bande passante mémoire. La génération de texte relit l’intégralité des poids à chaque jeton produit : la vitesse de restitution dépend donc directement du débit mémoire de la carte, bien plus que de sa puissance de calcul brute. C’est ce qui explique qu’un même modèle paraisse fluide sur une carte récente et poussif sur une carte plus ancienne, à capacité mémoire pourtant comparable.
Le cloud : ce que l’on achète réellement
Le service en ligne supprime ces contraintes et facture à la consommation, généralement au millier de jetons traités. Son avantage n’est pas seulement l’absence d’investissement : c’est l’accès immédiat aux modèles les plus volumineux, ceux qu’aucune PME n’hébergera jamais, et la mise à jour continue sans effort d’exploitation.
Le revers est double. D’abord la variabilité de la facture : un usage exploratoire coûte quelques euros par mois, mais un traitement automatisé branché sur un flux de documents peut faire décoller les volumes sans que personne ne s’en aperçoive avant la facturation. Ensuite la dépendance : tarifs, disponibilité et cycle de vie des modèles échappent au client, et un modèle retiré du catalogue impose de revalider tout ce qui reposait sur lui.
À l’inverse, le local offre une prévisibilité complète du coût — électricité et amortissement — et une latence indépendante de la qualité du lien Internet. C’est un argument concret pour les ateliers et sites industriels mal raccordés, où la connexion reste le maillon faible, comme nous l’évoquions à propos des plans de reprise informatique et de l’externalisation.
Le critère décisif : la donnée et son cadre juridique
C’est en réalité ici que se joue l’arbitrage, bien avant les considérations de matériel. Dès qu’un traitement porte sur des données à caractère personnel — dossiers clients, candidatures, échanges de support —, le recours à un service en ligne fait entrer un tiers dans la chaîne de traitement, avec les obligations qui en découlent.
La CNIL a publié un ensemble de fiches pratiques consacrées à l’IA — treize fiches complétées d’une liste de vérification — qui balisent précisément ces questions : détermination du régime juridique applicable, définition des finalités, qualification du rôle des fournisseurs de systèmes d’IA (responsable de traitement, responsable conjoint ou sous-traitant), base légale, analyse d’impact, sécurité durant le développement et information des personnes concernées. Cette troisième fiche est celle qui tranche le débat local/cloud sur le plan réglementaire : elle détermine qui porte la responsabilité de quoi.
À cela s’ajoute le calendrier du règlement européen sur l’IA. Aux termes de son article 113, les dispositions générales et l’interdiction de certaines pratiques s’appliquent depuis le 2 février 2025, les obligations relatives aux modèles à usage général et à la gouvernance depuis le 2 août 2025, et le règlement est entré en application générale le 2 août 2026. Parmi les obligations désormais actives figure la transparence des contenus générés, qui s’impose quel que soit le mode d’hébergement retenu.
Côté sécurité, l’ANSSI a publié dès le 29 avril 2024 des recommandations de sécurité pour les systèmes d’IA générative, destinées à sensibiliser administrations et entreprises aux risques associés et à promouvoir les bonnes pratiques, de la conception jusqu’au déploiement en production. Un déploiement local ne dispense de rien : il déplace la responsabilité de la sécurisation vers l’entreprise elle-même, avec les exigences de cloisonnement et de gestion des accès que cela suppose — les mêmes que celles évoquées à propos de la sécurité des datacenters.
Enfin, la montée des usages autonomes ajoute une couche : la CNIL et le Conseil de l’IA et du Numérique ont publié le 20 juillet 2026 une note exploratoire sur l’IA agentique et les données personnelles. Quand le système n’assiste plus mais agit — consulte des fichiers, déclenche des opérations —, la question de la maîtrise des données change de nature.
Où se situe la bascule
Une lecture pragmatique se dégage. Le local s’impose quand les données sont sensibles ou couvertes par un engagement de confidentialité, quand les volumes sont réguliers et prévisibles, quand la connexion constitue un point faible, ou quand la tâche est bien cernée — classification de documents, extraction d’informations, reformulation —, donc à la portée d’un modèle de taille moyenne. Ce sont d’ailleurs les mêmes logiques de spécialisation qui prévalent en reconnaissance d’images : un modèle ajusté à un usage précis bat souvent un modèle généraliste plus lourd.
Le cloud reste préférable pour les usages exploratoires, les besoins de raisonnement complexe, les pics ponctuels, et chaque fois que l’entreprise n’a ni la compétence ni le temps d’exploitation à consacrer à une infrastructure supplémentaire.
Dans les faits, l’architecture mixte est souvent la plus rationnelle : un modèle local pour les traitements de masse portant sur des données internes, un service en ligne pour les cas qui exigent la meilleure qualité de raisonnement, avec une règle explicite — écrite, connue des équipes — sur ce qui a le droit de sortir du réseau de l’entreprise. C’est cette règle, davantage que le choix technique lui-même, qui détermine si le déploiement est défendable devant un auditeur.