Le vrai coût de faire tourner l'IA en interne
L’argument habituel en faveur de l’IA locale est que vous cessez de payer des abonnements. Vous cessez bien de payer à l’utilisateur ou à la requête, et en échange vous payez du matériel, de l’électricité, l’installation et les heures de celui qui fait tourner la chose. Savoir si cela en vaut la peine dépend de vos volumes et de vos données, et c’est bien moins cher à calculer sur papier qu’après l’arrivée du matériel.
Ce que j’ai appris en la faisant tourner moi-même
Je teste des modèles locaux sur mon propre poste : une carte Nvidia de 16 Go, 64 Go de RAM, LM Studio pour faire tourner les modèles et OpenCode comme harnais qui les relie à mon IDE. Pour être clair, ce n’est certainement pas une configuration pour une grande entreprise, ni pour une entreprise de 20 personnes. Une configuration qui reste abordable pour une petite entreprise commencerait par une carte graphique de 32 Go. Avec les nouveaux modèles mixture-of-experts et la quantification, ce type de configuration peut faire tourner des modèles corrects pour le code et pour des tâches de complexité basique à modérée, et c’est plus que suffisant pour une aide simple à la rédaction et les tâches quotidiennes dont la plupart des employés ont besoin.
Jusqu’ici, j’ai utilisé les modèles de code pour construire de simples sites de test plutôt que sur mes vraies bases de code. Le code lui-même est correct. Le design ne l’est pas, mais cela ressemble à une question de configuration, puisque le volet design dépend des frameworks front-end avec lesquels le modèle doit travailler, et je pense que cela peut être résolu.
Ce qui m’a le plus surpris, c’est le temps que cela prend, même pour une configuration de test personnelle : la recherche, la configuration de l’environnement local, la découverte des modèles ouverts existants et de ce qu’ils savent faire, la connexion du harnais à mon IDE, la compréhension de la logique derrière les modèles et de la façon de régler leurs paramètres. Et de nouveaux modèles sortent régulièrement, avec de nouvelles façons de mieux exploiter le même matériel, donc une partie de ce travail ne s’arrête jamais vraiment. Pour une entreprise, un premier déploiement réaliste ressemble plutôt à dix jours de travail, parce que beaucoup de choses doivent se produire avant que quoi que ce soit ne soit installé : analyser les besoins de l’entreprise, choisir les cas d’usage, cartographier les données concernées, dimensionner le matériel et choisir les modèles, puis intégrer, tester sur de vrais exemples et former les personnes qui l’utiliseront.
Ce que vous payez
Je ne mets délibérément pas de prix sur le matériel ici. La bonne configuration dépend du nombre de personnes qui l’utilisent, des tâches et des modèles, et cela demande une analyse propre à chaque entreprise. Ce que je peux vous donner, c’est la liste des lignes à chiffrer, et l’endroit où se trouvent les surprises.
| Ligne de coût | Ce qui la détermine | Comment l’estimer |
|---|---|---|
| Matériel | La mémoire GPU avant tout ; 32 Go est un point de départ réaliste pour une petite entreprise | Des devis pour deux ou trois configurations, dimensionnés sur vos cas d’usage réels |
| Installation et intégration | La connexion des modèles aux outils que les gens utilisent déjà | Une dizaine de jours pour un premier déploiement, analyse des besoins comprise |
| Électricité | Que la machine tourne toute la journée ou à la demande | La mesurer pendant un mois plutôt que l’estimer |
| Maintenance et apprentissage | Nouveaux modèles, mises à jour, réglage des paramètres, réparation de ce qui casse | Des heures par mois, avec un nom en face |
La dernière ligne est celle que les gens oublient. L’installation est un projet avec un début et une fin, mais suivre les nouveaux modèles, les mises à jour et le réglage est un travail récurrent, et dans une entreprise ces heures sont du temps de travail de quelqu’un pris à autre chose, ou la facture d’un partenaire externe.
Ce qu’un modèle local peut et ne peut pas faire
| Tâche | Modèle local sur une configuration abordable | Pourquoi |
|---|---|---|
| Classer des documents ou des e-mails | Très adapté | Étroit, répétitif, facile à tester |
| Extraire des champs de factures, de formulaires, de contrats | Très adapté | Sortie structurée, critères de réussite clairs |
| Transcrire des réunions internes | Très adapté | Des modèles vocaux open source matures existent |
| Aide simple à la rédaction et tâches quotidiennes des employés | Adapté | Suffisant pour la plupart des besoins quotidiens sur une carte de 32 Go |
| Chercher et répondre à des questions sur des documents internes | Adapté | La qualité dépend plus de la façon dont vos documents sont organisés que du modèle |
| Code | Adapté | Code correct dans mes tests ; le design et le front-end demandent de la configuration |
| Textes soignés destinés aux clients | Peu adapté | Écart de qualité perceptible face aux meilleurs modèles cloud |
| Analyse complexe, raisonnement multi-étapes, stratégie | Peu adapté | C’est là que les modèles cloud de pointe justifient leur prix |
Si votre cas d’usage se trouve dans les deux dernières lignes, passer au local économise de l’argent au prix de la qualité. Demandez aux personnes qui l’utiliseront si elles l’acceptent, parce que sinon, elles retourneront discrètement au chatbot de leur téléphone et vous finirez par payer les deux.
Seuil de rentabilité
La comparaison, c’est ce que la même tâche vous coûterait dans le cloud chaque mois face au coût mensuel complet de la faire tourner vous-même.
Le local est rentable quand : coût cloud > (H + S) ÷ 36 + E + M — H est le matériel, S l’installation, E l’électricité mensuelle et M la maintenance mensuelle, sur un horizon de 36 mois. Mettez-y vos propres devis et vos propres heures. Si le seul terme de maintenance est supérieur à ce que vous payez actuellement pour les outils cloud que vous remplaceriez, vous avez déjà votre réponse.
En pratique, trois schémas reviennent. Avec un volume élevé sur une tâche étroite, disons des milliers de documents classés ou extraits chaque mois, le coût cloud croît à chaque requête tandis que le coût local reste fixe, et le local gagne généralement. Quand quelques personnes utilisent l’IA pour de la rédaction, de la recherche et de l’analyse variées, la dépense cloud reste modérée et la qualité compte davantage, donc le cloud gagne généralement largement. Et quand la carte des données de l’article précédent dit qu’une tâche ne peut pas du tout aller dans un cloud public, le coût cesse d’être le facteur décisif ; la vraie comparaison devient local contre service hébergé dans l’UE, et la même formule permet de la faire honnêtement.
La plupart des PME finissent par faire tourner les deux : une installation locale pour le travail sensible et à fort volume, et des outils en offre professionnelle ou hébergés dans l’UE pour tout le reste.
Avant d’acheter du matériel
- La tâche est-elle assez étroite et fréquente pour justifier des coûts fixes ?
- Avez-vous testé un modèle à poids ouverts sur 50 exemples réels et mesuré le taux d’erreur ?
- Votre carte des données (voir l’article précédent) exige-t-elle un traitement local, ou le préfère-t-elle seulement ?
- Qui s’en occupe, combien d’heures par mois, et qui reprend quand cette personne part ?
- Quel est le coût cloud que vous remplacez, mesuré plutôt qu’estimé ?
- Quel est votre plan quand un meilleur modèle sortira dans six mois ?
Où cela s’inscrit
C’est une décision à l’intérieur du processus que couvre mon Playbook ROI IA. Screen It vérifie si un cas d’usage mérite du tout l’attention. Do the Numbers donne le calcul complet du ROI, dont ce seuil de rentabilité est une entrée. Get It Approved le transforme en business case que vos associés ou votre conseil valideront, et Measure What Happened est le moment où vous vérifiez, six mois plus tard, si l’installation locale a tenu ce que le business case promettait.
Si vous ne faites qu’une chose après cet article, remplissez la ligne de maintenance avec un nom et un nombre d’heures. Et budgétez le premier déploiement en jours, une dizaine pour une petite entreprise, dont une bonne partie avant que quoi que ce soit ne soit installé.