Le tout-cloud s'est imposé sans débat dans les projets IA des PME françaises. Les éditeurs ont vendu la promesse d'une infrastructure sans friction, d'une scalabilité illimitée, d'un démarrage en quelques heures. Ces arguments sont réels. Leur revers est moins souvent présenté : une dépendance aux tarifs des grands fournisseurs de cloud, une exposition des données métier, et une facture qui augmente avec les volumes. Notre guide sur les coûts réels de l'IA en PME détaille ces postes. Le choix du tout-cloud mérite d'être réexaminé, par pragmatisme.
Ce que les hyperscalers ne mettent pas en avant dans leurs grilles tarifaires
Le modèle cloud IA repose sur une logique de consommation à l'usage : tokens traités, requêtes API, stockage de vecteurs, appels aux modèles. Individuellement, chaque poste semble maîtrisable. Agrégés sur douze mois, avec des volumes qui augmentent à mesure que les équipes adoptent les outils, ils produisent une trajectoire de coûts que peu de DAF anticipent correctement au moment du déploiement.
Le scénario type est le suivant : une PME démarre un projet de traitement documentaire sur Azure OpenAI ou AWS Bedrock, valide les premiers résultats, élargit le périmètre à d'autres équipes, et voit la facture croître avec le nombre d'utilisateurs et de documents traités. Sans suivi de la consommation par usage, la souplesse du paiement à l'usage devient difficile à piloter.
À cela s'ajoute la dépendance aux décisions unilatérales des fournisseurs : changements de modèles disponibles, évolutions tarifaires, suppressions de fonctionnalités. Les conditions d'utilisation des grands fournisseurs de modèles évoluent régulièrement, et d'anciens modèles sont retirés au profit de nouveaux. Construire une automatisation critique sur une API tierce, c'est accepter que ces règles changent, parfois avec un préavis court.
Pourquoi la question de la souveraineté des données n'est plus secondaire
Le RGPD a posé un cadre, mais il n'a pas suffi à changer toutes les pratiques. Beaucoup de PME envoient aujourd'hui des données contractuelles, des informations clients, des données RH ou des éléments de propriété intellectuelle vers des infrastructures dont elles ne maîtrisent ni la localisation exacte ni les conditions de traitement réelles.
La conformité RGPD des projets IA en PME concerne particulièrement les secteurs régulés : santé, services financiers, et les industries qui manipulent des données techniques sensibles. Un examen des sous-traitants révèle souvent des transferts de données que personne n'avait cartographiés au moment du déploiement.
L'on-premise ou le déploiement en cloud privé ne règlent pas la cybersécurité en général. Ils répondent à une question plus précise : qui a physiquement accès aux données que votre système IA traite, et sous quelle juridiction ? Pour certaines PME, la réponse actuelle est inconfortable.
Ce que l'on-premise permet réellement, et ce qu'il ne résout pas
Déployer un modèle en local ou sur une infrastructure privée n'est plus réservé aux grandes entreprises dotées d'équipes IT étoffées. L'arrivée de modèles à poids ouverts performants, dont plusieurs modèles Mistral adaptés au français, a changé l'équation. Des modèles de quelques milliards à quelques dizaines de milliards de paramètres tournent sur des serveurs GPU à la portée d'une ETI, voire d'une PME pour les plus petits.
Ce que l'on-premise apporte concrètement :
- Un coût par requête faible une fois l'infrastructure en place (électricité et maintenance restent à payer)
- Une maîtrise du flux de données, sans transfert vers des tiers
- Une indépendance aux évolutions tarifaires et aux changements de politique des éditeurs
- La capacité à fine-tuner un modèle sur des données métier propriétaires sans les exposer
Ce qu'il ne résout pas : la complexité d'intégration dans les systèmes existants, la maintenance de l'infrastructure, les mises à jour des modèles. Il faut aussi compter qu'un modèle ouvert hébergé chez soi est souvent moins performant que les meilleurs modèles commerciaux sur les tâches complexes. L'arbitrage entre cloud et on-premise se fait cas d'usage par cas d'usage, pas comme une position de principe.
L'arbitrage intelligent : cloud pour l'expérimentation, on-premise pour la production critique
Opposer cloud et on-premise a peu de sens pour une PME qui mène plusieurs projets IA à des stades différents. Une logique de séparation fonctionnelle est plus utile.
Le cloud reste pertinent pour la phase exploratoire : tester un cas d'usage, valider un modèle de traitement, prototyper rapidement. Le coût est acceptable sur des durées courtes et des volumes limités. L'infrastructure des hyperscalers offre une vitesse de démarrage que l'on-premise ne peut pas égaler.
En revanche, dès qu'un cas d'usage passe en production, qu'il traite des volumes significatifs, qu'il touche à des données sensibles ou qu'il est intégré dans un processus opérationnel critique, la question du rapatriement mérite d'être posée sérieusement. C'est à ce stade que les coûts cloud deviennent prévisibles sur le long terme, et donc comparables à un investissement infrastructure.
Concrètement, un cas d'usage peut démarrer sur une API publique puis migrer vers un déploiement privé une fois le traitement stabilisé. Pour que cette migration reste possible, il faut dès le départ isoler l'appel au modèle dans l'architecture et garder un jeu de tests qui permet de comparer les résultats des deux modèles.
Du prototype à l'industrialisation
Quand une organisation passe de l'expérimentation à l'industrialisation, des questions d'infrastructure apparaissent que la phase exploratoire permettait d'éviter. Empiler des outils SaaS d'IA sans architecture cohérente va vite au début ; définir une politique de traitement des données avant de déployer évite de devoir tout reprendre ensuite.
Le marché français a des caractéristiques propres : une sensibilité réglementaire forte, une base industrielle qui manipule des données techniques à haute valeur, et un tissu de PME/ETI qui n'ont pas les moyens de se payer les erreurs d'architecture que les grands groupes peuvent absorber. Ces contraintes sont des leviers si elles sont intégrées dès la conception du projet.
Quand l'automatisation IA devient un actif, pas une dépendance
Ce qui distingue un projet IA qui crée une valeur durable d'un projet qui crée une dépendance coûteuse, c'est la propriété effective de l'automatisation. Qui maîtrise le modèle ? Qui contrôle les données d'entraînement ? Qui peut faire évoluer le système sans repasser par un fournisseur tiers ?
Une automatisation IA structurée pour une PME qui répond oui à ces trois questions est un actif. Elle évolue selon les besoins du métier. Une automatisation entièrement liée à une API publique dont les conditions changent reste dépendante du fournisseur.
Cela ne condamne pas le cloud. Il s'agit de prendre la décision d'architecture consciemment, avec les bonnes variables dans l'équation, et non par défaut parce que le cloud était la solution la plus rapide à mettre en oeuvre au moment du lancement.
Par où commencer dans une PME
Pour chaque usage d'IA en production, notez le fournisseur, le volume mensuel, le coût mensuel et la sensibilité des données traitées. Les usages à fort volume ou à données sensibles sont les candidats à un hébergement privé ; les autres peuvent rester sur le cloud. Le guide IA, RGPD et souveraineté en PME compare les options d'hébergement, et la page coût de l'IA par mois aide à estimer la consommation. Pour faire cet arbitrage avec nous, vous pouvez demander un diagnostic gratuit.
Article rédigé par Louis Noyaret, cofondateur de Lumivi.
