Coût du conseil en IA pour les entreprises mid-market

La structure de PRIONATION est fixe et publique : un Diagnostic à 5 000–7 000 € sur deux semaines cartographie le goulot et fixe le périmètre ; un Build à 25 000–55 000 € sur huit semaines livre le système de production ; un Retainer à 4 000–9 000 €/mois maintient un pod disponible ensuite, avec un minimum de six mois. Un site Express de trois pages démarre à 1 500 €.

Plus de 60 % des Diagnostics débouchent sur un Build — un chiffre qui ne tient que parce que le Diagnostic est cadré pour qualifier le travail, pas pour vendre l'étape suivante à tout prix.

Le travail IA se vend de trois façons. L'horaire ou la régie reporte tout le risque d'imprévisibilité sur vous — le compteur tourne, que le travail converge ou non. Le périmètre fixe chiffre un résultat défini, donc le prestataire porte la variance. Le Retainer achète une capacité continue à un tarif mensuel prévisible.

Le point structurel : la régie récompense le prestataire quand le travail dure plus longtemps. Le périmètre fixe ne fonctionne que si le prestataire a une méthode qui élimine la variance — c'est pourquoi prix fixe et méthodologie sont inséparables.

Les coûts que les prestataires minimisent sont la montée en compétence, l'intégration et l'enfermement. La montée en compétence, ce sont les semaines facturées pendant qu'une équipe apprend votre domaine. L'intégration, c'est le travail ingrat de connexion à vos vrais systèmes, souvent cadré vaguement et facturé à mesure qu'il s'étend. L'enfermement, c'est le coût différé d'un système que vous ne pouvez ni exploiter ni quitter sans le prestataire.

Une mission à périmètre fixe avec infrastructure possédée élimine les trois : montée en compétence et intégration sont dans le prix fixe, et il n'y a rien dont s'enfermer puisque vous détenez tout.

Budgétez d'abord le Diagnostic — il est petit, et c'est lui qui rend le prix du Build fiable. Traitez tout prestataire qui chiffre un prix de Build fixe sans étape de cadrage comme devinant, ou prévoyant de facturer la différence plus tard.

Pour le coût total de possession, comptez ce que vous gardez : avec une infrastructure possédée, le Build est un actif que votre équipe peut exploiter, pas un abonnement au système d'autrui.

Le plus difficile dans une décision d'achat IA est rarement le chiffre affiché — c'est que deux devis pour le « même » projet décrivent des choses différentes. Les 30 000 € d'un prestataire couvrent un prototype fonctionnel ; ceux d'un autre couvrent un système de production avec evals, télémétrie et passation. Aucun ne ment, mais ils ne sont pas comparables, et un tableau côte à côte de tarifs journaliers masque précisément la différence qui compte. La seule façon de comparer honnêtement est de normaliser sur le livrable, pas sur le prix : ce qui tourne en production à la fin, qui le détient, et comment le « terminé » est défini.

Une méthode pratique consiste à écrire d'abord votre propre définition du terminé — le flux de travail, le critère de succès mesurable, les systèmes à connecter — et à demander à chaque prestataire de chiffrer face à cette seule spécification. Quand le livrable est fixe, les prix deviennent comparables et les écarts deviennent visibles : un devis très en dessous des autres omet généralement l'intégration, les evals ou la propriété, et cette omission est un coût que vous paierez plus tard plutôt qu'une économie. C'est la même discipline que produit un Diagnostic, et c'est pourquoi un devis ancré sur un Diagnostic cadré est plus fiable qu'un devis donné à froid.

La limite honnête est qu'aucune spécification n'élimine tout jugement — une équipe moins chère peut simplement être plus efficace, et une plus chère peut gonfler ses chiffres. Mais un livrable fixe transforme un vague « qui est le moins cher ? » en un précis « qu'achète réellement chaque prix ? », et cette question trouve presque toujours sa réponse une fois les livrables posés côte à côte.

Le devis le plus bas est fréquemment la mission la plus chère, car l'écart entre lui et les autres est rarement de la marge — c'est du périmètre discrètement laissé de côté. Un prix qui omet l'échafaudage d'evals livre un système dont personne ne peut prouver le bon fonctionnement ; un prix qui omet la télémétrie livre un système que personne ne peut déboguer ; un prix qui omet l'infrastructure possédée livre une dépendance que vous payez indéfiniment via un frais d'hébergement ou de « plateforme ». Le chiffre bon marché achète le build et reporte le reste en coûts qui surgissent après la signature du contrat, quand votre rapport de force est au plus bas.

Le motif à surveiller est le prix fixe chiffré sans étape de cadrage. Un prestataire qui nomme un chiffre de Build avant de cartographier vos données, vos points d'intégration et votre définition du « fonctionnel » absorbe soit un risque caché qu'il renégociera plus tard, soit prévoit de basculer en régie dès que le travail s'avère plus dur que ne le suggérait la démo. Les deux voies aboutissent au même endroit : le chiffre annoncé était un argument marketing, pas un engagement, et le vrai coût se découvre en cours de route.

Ce que cela ne peut pas corriger, c'est un acheteur qui optimise pour la ligne la plus basse d'un devis sans regarder ce qu'elle contient. La parade est de chiffrer le coût total de possession, pas le build seul — compter les frais récurrents, le travail à refaire et le coût de sortie — et de traiter un devis suspectement bas comme une question à poser plutôt qu'une économie à empocher.

Un build est une ligne unique ; la possession est une ligne récurrente, et les deux se comportent très différemment sur trois à cinq ans. Un système loué — hébergé par le prestataire, avec la logique dans une couche propriétaire — a un prix d'entrée bas et un frais mensuel sans fin, plus un coût de sortie qui croît plus vous restez. Un système possédé a un coût de build visible plus élevé, puis un coût de fonctionnement que vous contrôlez : l'usage du fournisseur de modèle, l'hébergement sur vos propres comptes, et la maintenance que vous choisissez, qu'il s'agisse d'un Retainer optionnel ou de votre propre équipe. Sur un horizon pluriannuel, la ligne récurrente domine la comparaison, et l'option louée d'apparence moins chère est fréquemment plus coûteuse dès la deuxième année.

La variable que la plupart des acheteurs sous-estiment est la sortie. Avec un système loué, partir signifie reconstruire, car rien de portable ne vous suit. Avec une infrastructure possédée — code dans votre dépôt, infrastructure définie comme du code, comptes de modèle et télémétrie à vos noms — le coût de sortie est quasiment nul, et cette liberté vaut de l'argent réel même si vous ne l'utilisez jamais. Dans ce modèle, un Retainer est un choix renouvelé sur la valeur plutôt qu'un frais auquel on ne peut échapper, ce qui garde le coût continu honnête puisqu'il peut toujours être annulé à l'échéance des six mois.

Modéliser correctement le coût total de possession recadre aussi le chiffre du build lui-même. Un Build à 25 000–55 000 € qui produit un actif que votre équipe peut exploiter n'est pas le même type de dépense que la même somme payée pour accéder à un système que vous ne détenez jamais — le premier apparaît une fois au bilan comme quelque chose que vous possédez, le second se répète à jamais comme quelque chose que vous louez.

Les questions les plus utiles sur le prix ne portent pas du tout sur le chiffre. Demandez qui détient le code, les comptes cloud et les clés de modèle à la fin — si la réponse est « nous l'hébergeons pour vous », le prix affiché est un droit d'entrée à un abonnement, pas le coût d'un actif. Demandez comment le « terminé » est défini et mesuré — s'il n'y a pas de suite d'evals, il n'y a pas de ligne d'arrivée convenue, et tout prix fixe chiffré face à une arrivée indéfinie est une supposition. Demandez ce qui se passe si la qualité de production dérive après le lancement — une vraie garantie nomme un seuil mesurable et une fenêtre ; un vague « nous vous accompagnerons » n'est pas un engagement opposable à qui que ce soit.

Posez ensuite directement la question des incitations : selon votre modèle, gagnez-vous plus en terminant ou en continuant ? La réponse révèle si l'intérêt du prestataire est aligné avec le vôtre avant qu'une seule ligne ne soit écrite. Associez-la à une demande de voir l'étape de cadrage — un prestataire confiant dans un prix fixe aura un mécanisme, comme un Diagnostic payant, qui cartographie la variance avant de s'engager sur un chiffre, et saura expliquer pourquoi le prix tient plutôt que de vous demander de croire qu'il tiendra.

Un signal d'alarme à nommer clairement : un prestataire qui résiste à chacune de ces questions, ou qui n'y répond que par des assurances plutôt que par un mécanisme. La propriété, les evals, la garantie et une étape de cadrage ne sont pas des options premium — ce sont la structure qui rend un prix fixe honnête, et leur absence n'est pas une remise mais une facture différée.