Internaliser ou sous-traiter un projet IA : comment décider ?

Pour décider s’il faut internaliser ou sous-traiter un projet IA, partez de cinq critères : la valeur stratégique du cas d’usage, la sensibilité des données, les compétences disponibles, la fréquence des évolutions et la capacité à piloter un prestataire. Une fonction différenciante, durable et étroitement liée au métier mérite davantage d’être maîtrisée en interne. Un besoin ponctuel, très spécialisé ou encore incertain se prête mieux à la sous-traitance. Dans beaucoup d’entreprises, le choix le plus solide reste hybride : garder le cadrage, les données et les décisions en interne, tout en achetant une expertise ciblée.

Le débat se résume mal à une comparaison de tarifs. Un devis externe peut sembler cher face à un salaire mensuel, mais une équipe interne implique aussi le recrutement, l’encadrement, l’infrastructure, la maintenance et la formation continue. À l’inverse, déléguer tout le projet peut créer une dépendance technique ou rendre les arbitrages opaques. La bonne question devient donc : quelles responsabilités l’entreprise doit-elle conserver, et pour quelles tâches a-t-elle intérêt à chercher un renfort extérieur ?

Commencer par cadrer le projet, pas par choisir un fournisseur

« Faire de l’IA » ne décrit aucun projet exploitable. Extraire des informations de factures, assister un service client, prévoir une demande ou intégrer un moteur de recommandation n’engage ni les mêmes données ni les mêmes compétences. Avant toute décision d’organisation, écrivez une fiche d’une page avec le problème métier, les utilisateurs, les données mobilisées, le résultat attendu et les limites à ne pas franchir.

Ajoutez un indicateur observable. Par exemple : réduire le temps consacré au tri de demandes tout en maintenant un taux d’erreur défini, ou aider un conseiller à retrouver une procédure sans répondre automatiquement au client. Cette précision évite de recruter un profil très technique pour un besoin qui pourrait être couvert par un logiciel existant. Elle évite aussi de confier au prestataire le soin de définir seul ce que l’entreprise cherche à obtenir.

Ce cadrage suppose une culture commune. Le dossier consacré aux compétences IA à développer dans l’entreprise détaille les rôles utiles, de la compréhension des usages jusqu’au pilotage et à la vérification. Sans interlocuteur métier disponible, aucune équipe externe ne peut compenser durablement l’absence de décisions internes.

Les critères qui font pencher vers l’internalisation

L’IA contribue directement à votre avantage métier

Si la solution repose sur un savoir-faire propre, des règles de décision originales ou un produit qui évolue chaque semaine, la capacité à modifier le système devient stratégique. Internaliser ne signifie pas forcément entraîner un modèle de fondation. Cela peut consister à posséder l’architecture, les évaluations, le code d’intégration et la connaissance des données, même si l’entreprise utilise des modèles fournis par un tiers.

Le besoin est récurrent et alimente une feuille de route

Une équipe interne prend du sens lorsque plusieurs cas d’usage doivent être entretenus, surveillés et améliorés. Un prototype n’est pas un produit fini : les données changent, les utilisateurs détournent parfois la fonction prévue et les performances peuvent se dégrader. Si personne ne doit reprendre le sujet après la livraison, le projet risque de rester une démonstration sans propriétaire.

Les données et les arbitrages exigent une maîtrise étroite

Des données personnelles, des secrets d’affaires ou des décisions affectant des personnes imposent une gouvernance précise. La CNIL rappelle que les traitements d’IA utilisant des données personnelles doivent respecter les principes du RGPD, notamment la finalité, la pertinence des données et leur durée de conservation. Internaliser peut faciliter le contrôle, mais ce n’est pas une garantie automatique. Une équipe interne sans politique d’accès ni documentation reste exposée.

Le règlement européen sur l’intelligence artificielle adopte par ailleurs une logique fondée sur les risques et attribue des obligations aux différents acteurs. La présentation officielle de la Commission européenne constitue un bon point de départ pour identifier le cadre applicable. Le statut de fournisseur, de déployeur ou d’importateur ne se déduit pas simplement de la présence d’un prestataire : il dépend de la manière dont le système est conçu, commercialisé et utilisé.

Quand la sous-traitance est plus raisonnable

Vous devez lever une incertitude précise

Pour une étude de faisabilité, une revue d’architecture, un prototype limité ou un audit de sécurité, mobiliser une compétence extérieure pendant quelques semaines est souvent plus cohérent que créer immédiatement un poste. Le prestataire apporte alors une expertise identifiable et un livrable qui aide l’entreprise à décider. Le périmètre doit rester assez court pour que l’expérimentation ne se transforme pas silencieusement en dépendance.

La compétence nécessaire est rare ou temporaire

Un projet peut demander ponctuellement un spécialiste de la vision, de l’évaluation des modèles, de la cybersécurité ou de l’infrastructure. Réunir tous ces profils en interne n’est pas toujours réaliste. La sous-traitance permet de composer une équipe adaptée à une phase donnée, à condition d’exiger de la documentation et un transfert de connaissances.

Le cas d’usage n’est pas différenciant

Une fonction standard, comme la recherche dans une base documentaire ou le classement initial de messages, ne justifie pas forcément un développement propriétaire. Avant de sous-traiter du sur-mesure, comparez aussi les solutions déjà disponibles. Le choix réel comporte souvent trois options : acheter un outil, faire construire une intégration ou développer en interne.

L’urgence seule ne doit cependant pas décider. Une mise en production rapide, sans règles d’accès ni scénario de repli, peut déplacer le coût vers la sécurité et la maintenance. Le guide de l’ANSSI consacré aux systèmes d’IA générative insiste sur une posture de prudence dès la conception et sur la sécurisation de l’architecture jusqu’au déploiement.

Une grille de décision pour comparer les trois modèles

Situation	Option à privilégier	Point de vigilance
Cas d’usage ponctuel, résultat encore incertain	Prestataire pour une étude ou un prototype borné	Définir les critères d’arrêt et la propriété des livrables
Fonction standard déjà couverte par le marché	Solution existante, avec intégration interne ou externe	Vérifier la réversibilité, les données et les coûts d’usage
Produit IA au cœur de la proposition de valeur	Noyau interne renforcé ponctuellement	Ne pas dépendre d’une seule personne
Données sensibles et nombreux usages récurrents	Gouvernance interne, expertise externe ciblée	Contractualiser les accès, la sécurité et les responsabilités
Équipe métier solide mais compétence technique incomplète	Modèle hybride avec transfert organisé	Prévoir du temps interne pour apprendre et reprendre

Pour chaque ligne de votre projet, attribuez une note simple de 1 à 5 aux six dimensions suivantes : importance stratégique, sensibilité des données, durée du besoin, disponibilité des compétences, urgence et capacité de supervision. Une forte importance stratégique et un besoin durable favorisent l’interne. Une forte urgence associée à un besoin court favorise un prestataire. Une forte sensibilité des données appelle surtout une gouvernance exigeante, quel que soit le modèle.

Le modèle hybride : séparer la maîtrise de l’exécution

Le modèle hybride n’est pas un compromis flou si les responsabilités sont écrites. L’entreprise peut conserver le sponsor, le responsable produit, l’expert métier, la gouvernance des données et la validation des résultats. Le partenaire intervient alors sur une brique identifiée : architecture, développement, sécurité, industrialisation ou montée en compétence.

Une répartition concrète peut ressembler à ceci :

• en interne : choix du problème, accès aux données, définition des erreurs inacceptables, validation métier et décision de mise en production ;
• en externe : réalisation technique délimitée, recommandations d’architecture, tests spécialisés et documentation ;
• en commun : critères d’évaluation, suivi des incidents, calendrier de transfert et revue des risques.

Cette organisation oblige l’entreprise à développer assez de compétences pour challenger une proposition sans prétendre tout construire seule. Si une montée en compétence plus large est nécessaire, mieux vaut choisir un parcours IA adapté aux rôles et au projet plutôt qu’une initiation identique pour toute l’équipe.

Ce que le contrat doit protéger avant le démarrage

Un bon contrat ne remplace pas le pilotage, mais il évite plusieurs zones grises. Faites préciser les livrables, les jalons, les critères d’acceptation, les responsabilités en cas d’incident et les conditions de sortie. Demandez où les données sont traitées, qui peut y accéder, combien de temps elles sont conservées et si elles servent à améliorer un service tiers.

La réversibilité mérite une clause dédiée. L’entreprise doit pouvoir récupérer le code convenu, la configuration, les schémas de données, les jeux de tests, les instructions de déploiement et la documentation. Vérifiez aussi les licences des composants, les dépendances à des services externes et la procédure à suivre si un modèle ou une API disparaît.

Enfin, prévoyez le transfert dès le devis, pas à la dernière semaine. Des points techniques enregistrés, une documentation relue par l’équipe interne et une phase de fonctionnement en binôme valent mieux qu’un dossier volumineux livré sans explication.

Décider en deux étapes plutôt qu’en un pari définitif

Une décision saine peut se prendre en deux temps. D’abord, financez une phase courte qui vérifie la faisabilité, la qualité des données, les risques et la valeur d’usage. Ensuite seulement, choisissez le modèle d’exploitation : équipe interne, solution du marché, partenaire récurrent ou combinaison des trois.

Fixez avant l’expérimentation les conditions qui justifieraient une internalisation : volume de demandes, nombre de produits concernés, fréquence des évolutions, niveau de criticité ou besoin de préserver une connaissance propre. Vous éviterez de recruter sur la base d’un effet de mode comme de prolonger indéfiniment une mission externe devenue structurelle.

Le choix n’a donc rien d’irréversible. Sous-traiter peut servir à apprendre avant de reprendre une partie du système. Internaliser peut aussi révéler qu’une brique standard gagnerait à être achetée. L’objectif n’est pas de défendre un modèle, mais de conserver la capacité de comprendre, contrôler et faire évoluer ce qui compte réellement pour l’entreprise.

Camille Renaud, signature éditoriale d’ADE University.