Compétences IA : recruter, former ou externaliser ?

La question se pose dans presque tous les comités de direction qui abordent l'IA : faut-il recruter des experts, former les équipes en place, ou faire appel à l'extérieur ? Elle est généralement traitée comme un arbitrage budgétaire. C'est une erreur de cadrage. Le bon critère n'est pas le coût, c'est la nature de la compétence dont l'organisation a besoin — et cette nature change selon la phase où elle se trouve.

Il faut d'abord défaire une confusion. « Compétence IA » désigne au moins quatre métiers distincts, dont les marchés du travail n'ont rien à voir. Le data scientist conçoit des modèles. L'ingénieur data construit et maintient les flux qui les alimentent — c'est aujourd'hui la ressource la plus rare et la plus déterminante. L'ingénieur de mise en production, souvent appelé MLOps, fait tenir ces systèmes dans la durée. Et le traducteur métier, profil hybride sans titre stable, sait convertir un problème opérationnel en question traitable par un modèle. Une organisation qui recrute trois data scientists sans ingénieur data obtient trois personnes très qualifiées qui passeront la moitié de leur temps à faire du travail de plomberie qu'elles n'aiment pas et pour lequel elles n'ont pas été formées.

Le recrutement se justifie quand la compétence doit être permanente, exercée quotidiennement, et nourrie par la connaissance interne de l'organisation. C'est typiquement le cas de l'ingénierie data et de la mise en production : ces métiers reposent sur une connaissance fine des systèmes maison qui ne s'achète pas et se perd à chaque rotation. Le recrutement suppose en revanche une capacité à retenir. Recruter un profil rare dans une organisation qui ne peut lui offrir ni projets stimulants, ni progression, ni environnement technique correct, c'est financer la formation d'un concurrent.

La formation interne se justifie quand la compétence à développer est adjacente à un métier déjà maîtrisé. Former un analyste financier à interroger un modèle, un juriste à évaluer une décision automatisée, un contrôleur de gestion à lire les limites d'une prédiction : ces montées en compétence fonctionnent parce que le socle métier est déjà là et que seule la couche technique manque. À l'inverse, l'idée de transformer des équipes non techniques en praticiens de la data science par un programme de quelques semaines produit surtout de la frustration.

Le recours externe se justifie dans deux situations, et deux seulement. La première est le besoin ponctuel d'une expertise rare qu'il serait absurde d'internaliser : un cadrage stratégique, une architecture, un audit de conformité. La seconde est le transfert de compétence — faire venir quelqu'un précisément pour que l'organisation sache faire seule ensuite. Toute autre configuration crée une dépendance qui se paie longtemps.

Le cas ci-dessous est reconstruit à partir de plusieurs situations comparables, non copié d'une entreprise précise. Une entreprise recrute une équipe data science de six personnes, avec des profils solides et des salaires au niveau du marché. Dix-huit mois plus tard, quatre sont partis. L'enquête de départ ne mentionne ni la rémunération ni l'ambiance. Elle mentionne trois choses : l'absence d'accès aux données de production, des délais de plusieurs mois pour obtenir un environnement de travail, et le sentiment que les modèles livrés n'étaient jamais déployés. L'organisation n'avait pas un problème de recrutement. Elle avait un problème de conditions d'exercice, et le recrutement l'a simplement rendu visible et coûteux.

C'est un point sur lequel nous insistons systématiquement : avant de se demander comment attirer des compétences IA, une organisation doit se demander si elle est en état de les employer. Chez KAIROS Impulse, cette vérification précède toute recommandation de dimensionnement d'équipe. Elle porte sur quatre éléments concrets : l'accès aux données, la disponibilité d'environnements techniques, l'existence d'un chemin de mise en production, et la présence d'un sponsor métier pour chaque cas d'usage. Sans ces quatre conditions, le meilleur recrutement échouera, et l'échec sera attribué aux personnes plutôt qu'au dispositif.

Une objection légitime concerne le rythme. Attendre d'avoir réuni ces conditions retarderait l'entrée dans le sujet, alors que le marché avance. La réponse tient dans le séquencement : la première compétence à sécuriser n'est pas le data scientist mais l'ingénieur data, parce que c'est lui qui construit les conditions dans lesquelles les autres pourront travailler. Beaucoup d'organisations font l'inverse et s'étonnent du résultat.

Un dernier facteur pèse plus lourd que tous les autres et n'apparaît dans aucun budget : la capacité à faire progresser les gens. Les métiers de l'IA évoluent vite, et un professionnel qui sent sa compétence se dévaluer partira, quel que soit son salaire. Le temps consacré à la veille, à l'expérimentation, à la formation continue n'est pas une charge : c'est la condition de la rétention. Les organisations qui l'accordent conservent leurs équipes ; celles qui le refusent au nom de la charge de projet recrutent en permanence.

Trois questions, pour finir. De quelle compétence avons-nous réellement besoin — concevoir des modèles, construire des flux de données, exploiter des systèmes, ou traduire des besoins métier ? Sommes-nous en état d'offrir à cette personne un environnement où elle pourra travailler dès le premier mois ? Et si nous faisons appel à l'extérieur, avons-nous défini ce que nous devrons savoir faire seuls à la fin de la mission ?