Externaliser un projet IA : régie, forfait ou build & run — quel modèle pour quel projet

L'achat IT a une mémoire musculaire : sur un projet de transformation, on tend par défaut vers le forfait. Périmètre cadré, livrables datés, pénalités contractuelles — la direction des achats sait tarifer le risque, la DSI sait piloter l'avancement. Sur un projet IA, ce réflexe transforme un sujet d'innovation en source de litige. La donnée d'entrée n'est pas qualifiée, le modèle qu'on espérait calibrer atteint un plafond de précision plus bas que prévu, le métier découvre en cours de route que le cas d'usage cible n'est pas celui qui crée le plus de valeur. Le forfait, c'est de l'engagement de résultat sur un livrable dont on ne connaît pas encore les contours techniques.

Sur les missions IA que nous voyons passer chez les CAC40 et ETI 500+, le débat « régie ou forfait » est souvent caricatural — comme si seuls deux modes existaient. La réalité du marché est plus granulaire : régie pure, forfait pur, hybride avec phases distinctes, build & run avec engagement opérationnel. Chaque modèle a son terrain de jeu, et chaque modèle a son angle mort. Choisir le bon, c'est d'abord savoir lire la maturité de son propre projet.

Pourquoi le forfait pur ne marche pas sur l'IA

Un forfait suppose trois prérequis : un périmètre fonctionnel stable, une volumétrie de données connue, une définition du « fini » qui ne laisse pas de place à l'interprétation. Sur un projet d'intégration ERP ou de refonte d'un portail, ces trois points sont vérifiables au moment de la signature. Sur un projet IA, ils ne le sont presque jamais.

Trois mécaniques propres à l'IA cassent l'équation forfaitaire :

• L'incertitude sur la donnée. Le prestataire signe avant d'avoir vu un seul fichier. La qualité réelle du jeu d'apprentissage, la profondeur historique, le taux de complétude des champs critiques — tout ça est découvert après, et tout ça change la trajectoire du projet.
• L'incertitude sur la performance atteignable. Annoncer 92 % de précision avant d'avoir entraîné le modèle relève du pari. Le plafond technique dépend de la donnée, de la classe du modèle, du bruit dans les libellés. Un forfait avec un seuil de précision contractualisé sans phase exploratoire pousse le prestataire à choisir le seuil le plus bas qu'il peut défendre — ce qui n'est pas l'intérêt du client.
• L'incertitude sur le cas d'usage. Le métier formule rarement le bon problème dès le départ. Les retours d'expérience publiés par le CIGREF le confirment de manière récurrente : le cas d'usage initial évolue significativement entre le cadrage et la mise en production utile.

Quand un acheteur impose le forfait sur un projet à ces trois inconnues, le prestataire applique un coussin de risque substantiel pour absorber l'aléa technique. Le client paie cher pour avoir l'illusion de la sécurité contractuelle — sécurité qui s'évapore au premier avenant, parce que les avenants sont inévitables.

La régie pure : ses avantages et son angle mort

La régie inverse complètement la logique. Le prestataire facture au temps passé, sans engagement de livrable. Le client garde la main sur la direction du projet, peut pivoter à tout moment, ajuster le périmètre selon les apprentissages. C'est le modèle naturel pour la phase d'exploration : POC, qualification de données, itération sur les premiers prototypes de modèles.

Son angle mort est exactement symétrique à celui du forfait : aucune garantie de résultat. Le prestataire n'a pas d'engagement contractuel sur la performance, sur l'arrivée à un livrable, sur la mise en production. Sur un projet structurant — surtout au-delà de la phase POC — la régie pure laisse la responsabilité du delivery uniquement sur les épaules du client, qui la plupart du temps n'a pas l'expérience IA pour porter cette responsabilité seule.

L'autre piège de la régie : la dépendance qui s'installe. Sans engagement contractuel sur la documentation, la transmission de compétences, la réversibilité, on se retrouve six mois plus tard avec un système en production que personne en interne ne sait faire évoluer. Le prestataire facture alors la maintenance au tarif qu'il veut — la situation est verrouillée.

Le modèle hybride : cadrage forfait + delivery régie avec jalons

Le modèle qui résiste le mieux aux particularités de l'IA, et qu'on voit s'imposer chez les directions achats matures, est l'hybride structuré en phases distinctes. La logique : forfait sur ce qui est cadrable, régie sur ce qui ne l'est pas, jalons go/no-go entre les deux.

La phase 1 — cadrage, audit de données, choix d'architecture, POC — est forfaitisée parce que son périmètre est connu : nombre d'ateliers, nombre de jeux de données à analyser, livrable de fin de phase identifié. L'engagement de résultat porte sur la production d'un avis argumenté (le projet est-il faisable ? avec quelle classe de modèle ? quel risque ?), pas sur une précision de modèle.

La phase 2 — industrialisation, mise en production, itération — est facturée en régie avec jalons trimestriels. Chaque jalon est un point d'arrêt contractuel : si la performance n'est pas atteinte, le client peut sortir sans pénalité. Cette structure aligne les intérêts : le prestataire a tout à gagner à atteindre les jalons, le client garde sa porte de sortie.

Le build & run : pour qui ?

Le build & run pousse la logique un cran plus loin : le prestataire construit la solution IA et l'opère en production sur la durée, avec des engagements de service (disponibilité, performance, dérive du modèle, temps de remédiation). Le contrat ne porte plus sur un livrable mais sur un service rendu.

Ce modèle s'adresse à des organisations avec un profil bien précis :

• Pas d'équipe data science interne capable d'opérer un modèle en production (réentraînement, supervision, gestion du drift). Recruter et retenir cette équipe coûte plus cher que d'externaliser le run.
• Cas d'usage non stratégique mais opérationnellement nécessaire — détection de fraude basique, scoring de leads, classification documentaire. La performance compte, mais le modèle n'est pas un actif différenciant à internaliser.
• Volonté de transférer le risque opérationnel sur un prestataire qui prend l'engagement contractuel de tenir un SLA dans le temps, avec pénalités si le modèle dérive.

L'inverse est tout aussi vrai. Sur un cas d'usage stratégique (le modèle de recommandation produit chez un retailer, le modèle de pricing chez un assureur), externaliser le run revient à externaliser un avantage concurrentiel — c'est rarement la bonne décision. Le build & run convient au commodity AI, pas au core AI.

Le scope du contrat IA : ce qu'il doit absolument couvrir

Au-delà du choix du modèle de prestation, ce qui distingue un contrat IA bien rédigé d'un contrat hérité de l'intégration applicative classique, c'est la couverture de cinq zones spécifiques que les modèles Syntec Numérique standards traitent peu ou mal :

• Le périmètre des données. Quelles données sont fournies par le client, lesquelles sont enrichies par le prestataire (datasets externes, données synthétiques), qui en porte la responsabilité au sens RGPD, et que devient ce périmètre en fin de contrat.
• La performance attendue. Préciser un seuil minimum de performance (précision, rappel, F1, ou métrique métier directement) après la phase de cadrage, pas avant. La performance contractualisée doit être mesurable, vérifiable et liée à un protocole de test fourni en annexe.
• Le réentraînement et la dérive. Qui prend en charge le monitoring de drift, à quelle fréquence le modèle est réentraîné, sur quelles données, avec quel processus de validation. Sans cette clause, on se retrouve à payer trois fois pour le même service un an plus tard.
• La conformité AI Act. Pour un système haut risque, le prestataire doit fournir la documentation technique exigée par le règlement, participer aux audits, et garantir la mise à jour de cette documentation à chaque évolution majeure du modèle.
• Le service après mise en production. Niveaux de service, temps de remédiation en cas d'incident, traçabilité des décisions prises par le modèle (logging structuré), procédure de rollback si une nouvelle version dégrade la performance.

Les 5 clauses contractuelles clés

Au-delà du scope, cinq clauses méritent une attention particulière dans un contrat IA. Aucune n'est optionnelle dès lors que le projet dépasse le POC.

Sur les contrats que nous voyons passer en revue chez nos clients du secteur financier ou industriel, ces cinq clauses sont rarement toutes présentes au premier draft fourni par l'ESN ou l'éditeur. Elles s'obtiennent en négociation — et c'est précisément la valeur d'un cabinet IA tiers qui aide la direction des achats à savoir où poser le curseur. Le sujet recoupe nos retours d'expérience publiés dans cabinet IA vs ESN et dans la comparaison consultant IA vs cabinet.

Le bon modèle pour le bon moment du projet

L'erreur stratégique la plus coûteuse n'est pas de choisir le mauvais modèle — c'est de choisir un modèle unique pour tout un cycle qui en demanderait trois. Un projet IA mature traverse en réalité trois phases distinctes : exploration (POC, qualification donnée), industrialisation (mise en production), exploitation (run, évolution). Chaque phase a son modèle de prestation optimal.

Les travaux publiés par Numeum sur les contrats de prestation IT vont dans le même sens : la segmentation contractuelle par phase, avec changement de modèle de facturation à chaque palier, est mieux adaptée à la nature exploratoire des projets IA que le forfait global couvrant l'ensemble du cycle. Nous recommandons systématiquement cette segmentation à nos clients qui démarrent une transformation IA — c'est un point que nous traitons en détail dans notre note sur le coût d'un projet IA et qui structure notre approche d'expertise GenAI.

Ce qui compte au moment de signer : avoir verrouillé les jalons de sortie, la propriété des actifs produits, et la trajectoire d'évolution. Le prix négocié au mois 1 est secondaire — la vraie économie se fait sur la capacité à pivoter au mois 9 sans repartir de zéro.