Ce que coûte réellement l’intégration d’une IA en PME : les postes qu’on oublie
Le coût des appels au modèle est la partie visible, et souvent la plus faible. Les postes qui font dériver un budget sont ailleurs, et ils sont prévisibles, à condition de les avoir listés avant de commencer.
Christophe Bellec ·
Réponse courte
Le coût d’un projet d’intégration IA se répartit en trois blocs : la mise en état des données et du système d’information, souvent le plus lourd ; le développement de l’intégration elle-même ; et l’exploitation, qui comprend un coût variable par usage. Les appels au modèle représentent en général une part minoritaire du total. Un POC qui coûte quelques jours ne préjuge pas du coût de mise en production, qui est un projet logiciel à part entière.
Pourquoi les estimations dérapent
Une démonstration convaincante se construit en une journée. Elle donne l’impression que l’essentiel est fait, alors qu’elle a écarté tout ce qui coûte : les données réelles, les droits d’accès, les cas particuliers, les erreurs, l’intégration au reste du système.
La marche entre un prototype et un service exploitable n’est pas propre à l’IA : c’est la même que pour n’importe quel logiciel. Ce qui est propre à l’IA, c’est qu’elle est particulièrement facile à franchir en apparence, et particulièrement coûteuse à franchir réellement.
Les postes de coût, du plus oublié au plus visible
1. La mise en état des données
C’est le poste le plus systématiquement sous-estimé. Les documents sont éparpillés entre un serveur de fichiers, une messagerie et trois outils SaaS ; les référentiels comportent des doublons ; personne ne sait quelle version d’une procédure fait foi. Aucune IA ne corrige cela.
Bonne nouvelle : ce travail a de la valeur indépendamment du projet IA. Mauvaise nouvelle : il doit être fait avant, et il ne se sous-traite pas entièrement, car il demande de savoir ce qui fait autorité dans l’entreprise.
2. L’intégration au système existant
Une fonctionnalité IA utile n’est pas une interface séparée : elle vit dans les outils que les équipes utilisent déjà. Cela suppose des APIs, une authentification, une gestion d’erreurs, parfois l’ouverture d’un système qui n’a jamais été conçu pour être appelé de l’extérieur. C’est du développement classique, et c’est souvent le plus gros poste de la phase de réalisation.
3. Les droits d’accès
Dès que le service touche des données qui ne sont pas lisibles par tous, il faut décider comment les permissions s’appliquent, les implémenter, et pouvoir le démontrer. Traité au début, c’est une contrainte de conception. Traité à la fin, c’est une refonte.
4. L’évaluation
Un système IA n’a pas de « ça marche » binaire. Il faut un jeu de questions de référence avec les réponses attendues, sinon personne ne peut dire si une modification améliore ou dégrade le service. Constituer ce jeu demande du temps métier, pas du temps technique, et c’est précisément pour cela qu’il est souvent sauté.
5. L’exploitation
Journalisation, supervision, alertes, suivi des coûts, gestion des indisponibilités du fournisseur, montées de version des modèles. Un modèle remplacé peut changer le comportement du service : sans jeu d’évaluation, cette montée de version devient un pari.
6. Le coût variable par usage
C’est le seul poste réellement nouveau par rapport à un projet logiciel classique : le service coûte à chaque utilisation. Ce coût dépend de la taille du contexte envoyé, du modèle choisi et du volume d’usage : trois paramètres sur lesquels l’architecture a une prise directe.
7. La conduite du changement
Un outil que personne n’utilise coûte cent pour cent de son budget pour zéro bénéfice. Il faut former, expliquer les limites, et prévoir quoi faire quand le système se trompe, parce qu’il se trompera.
Comment estimer avant de s’engager
Sans connaître votre contexte, personne ne peut annoncer un chiffre honnête. En revanche, ces questions permettent de situer l’ordre de grandeur, et elles se répondent en quelques jours :
- Sur quelles données repose le cas d’usage, et dans quel état sont-elles réellement ?
- Existe-t-il déjà une API pour y accéder, ou faut-il l’écrire ?
- Qui a le droit de voir quoi, et ce modèle d’autorisation est-il déjà implémenté quelque part ?
- À quelle fréquence le service sera-t-il utilisé, et par combien de personnes ?
- Que se passe-t-il si la réponse est fausse ? Un texte à relire ou une décision engageante ne demandent pas le même niveau de garanties.
- Qui exploitera le service une fois livré ?
La question 5 est celle qui déplace le plus le budget. Un assistant de rédaction relu par un humain et un système qui déclenche une action sans validation n’appartiennent pas au même projet, ni au même ordre de grandeur.
Comment réduire la facture sans dégrader le résultat
- Commencer par un seul cas d’usage, mesurable, avec un utilisateur identifié qui en a besoin chaque semaine.
- Lire les données en direct plutôt que de construire un index à maintenir, quand c’est possible.
- Choisir le modèle après avoir défini l’architecture : un modèle plus petit suffit pour la plupart des étapes d’un pipeline.
- Réduire le contexte envoyé : la qualité de la récupération pèse plus sur le coût que le choix du modèle.
- Mettre en cache ce qui est stable, et mesurer le coût par usage dès le premier jour.
- Décider d’un critère d’arrêt avant de commencer : si le POC ne l’atteint pas, on ne poursuit pas.
Le POC n’est pas une version 1
Un POC sert à lever une incertitude précise, en quelques jours, sur des données réelles : la récupération trouve-t-elle les bons documents ? Le modèle produit-il un résultat exploitable ? Le coût par usage est-il acceptable ? Sa réussite autorise à investir dans la suite ; elle ne dit rien du coût de cette suite.
Confondre les deux est la raison la plus fréquente d’un budget annoncé trois fois trop bas. Séparer explicitement les deux phases, et les budgéter séparément, évite la mauvaise surprise.
Questions fréquentes
Quel est le poste de coût le plus souvent oublié ?
La mise en état des données, suivie de l’évaluation. Le premier est invisible dans une démonstration, le second n’intéresse personne tant que le système n’a pas encore donné de mauvaise réponse en production.
Les appels au modèle représentent-ils l’essentiel du budget ?
Rarement. Sur un projet d’intégration, ils constituent généralement une part minoritaire du coût total, très loin derrière le développement et la préparation des données. Ils deviennent significatifs sur des volumes élevés, et c’est alors l’architecture qui les fait baisser.
Peut-on commencer petit ?
C’est même la seule approche raisonnable : un cas d’usage, un utilisateur type, un critère de réussite défini à l’avance. Le POC dure quelques jours et tranche une question précise, plutôt que d’ouvrir un chantier dont personne ne connaît la fin.
Comment savoir si le projet en vaut la peine avant de le lancer ?
En chiffrant le temps réellement passé aujourd’hui sur la tâche visée, et en le comparant au coût d’intégration estimé. C’est l’objet d’un audit IA et métier : trier les cas d’usage par impact et par complexité, y compris ceux qu’il vaut mieux ne pas lancer.