Comment composer une équipe capable de construire une IA sectorielle ?

Une startup souhaite créer un assistant qui aide les élèves à comprendre leurs exercices. Elle recrute un développeur, choisit un modèle de langage et réalise une démonstration convaincante. Mais, au moment de déployer le service, de nouvelles questions surgissent : qui garantit la conformité aux programmes ? Qui vérifie les corrigés ? Qui explique les erreurs fréquentes ? Qui décide qu’une nouvelle version peut être publiée ?

Ces questions révèlent un enjeu souvent sous-estimé : une application d’intelligence artificielle sectorielle ne repose pas seulement sur une architecture technique. Elle dépend aussi d’une organisation du travail et de compétences capables de transformer des connaissances métier en ressources fiables.

Pour constituer une équipe, le bon point de départ n’est donc pas une liste standard de métiers de l’IA. Il est l’analyse des fonctions à assurer, des risques à maîtriser et des résultats attendus.

Un assistant documentaire destiné à rechercher des passages de référence n’exige pas la même organisation qu’un outil chargé de vérifier des calculs, de proposer des recommandations agricoles ou d’accompagner une procédure administrative.

Il faut d’abord définir les utilisateurs, les tâches, les connaissances nécessaires, les limites du service et les critères de réussite. Cette analyse permet de distinguer les opérations qui relèvent du modèle, celles qui exigent des outils spécialisés et celles qui doivent être validées par des experts du domaine.

La composition de l’équipe doit ensuite découler de ces besoins. Recruter de nombreux spécialistes sans périmètre précis peut augmenter les coûts sans améliorer la qualité. À l’inverse, une équipe réduite peut fonctionner efficacement si elle couvre les responsabilités critiques.

Une première fonction est la responsabilité métier : comprendre les besoins, expliciter les règles, définir les usages acceptables et valider le contenu sectoriel. Une deuxième est l’ingénierie des connaissances : identifier les sources, formaliser les savoirs et préparer les représentations nécessaires.

La troisième fonction est l’ingénierie technique : développer l’application, intégrer les modèles, les services de recherche, les bases de données et les mécanismes de sécurité. La quatrième est l’assurance qualité et la gouvernance : définir les tests, gérer les versions, traiter les incidents et encadrer les autorisations.

Ces quatre fonctions ne correspondent pas nécessairement à quatre personnes. Elles constituent une grille de responsabilités. Dans un petit projet, certaines peuvent être réunies ; dans un système critique ou mutualisé, elles devront parfois être exercées par des équipes distinctes.

Le référentiel « Les compétences invisibles de l’intelligence artificielle » propose huit familles : ingénierie documentaire ; ingénierie des connaissances ; ingénierie ontologique et sémantique ; ingénierie des données ; ingénierie cognitive ; ingénierie pédagogique et sectorielle ; curation et gouvernance ; évaluation des systèmes d’IA métier.

Cette classification ne constitue pas huit nouveaux postes à créer. Elle permet de vérifier que les opérations essentielles sont couvertes. Par exemple, la préparation d’un corpus pédagogique mobilise l’ingénierie documentaire ; la description des méthodes d’enseignement mobilise l’expertise pédagogique et l’ingénierie des connaissances ; la vérification des réponses mobilise l’évaluation métier.

Le développeur peut maîtriser certaines de ces fonctions, mais ne doit pas être supposé compétent pour approuver seul une règle juridique, un corrigé scientifique ou une recommandation médicale.

Pour un prototype limité, une petite équipe peut associer un responsable produit, un développeur intégrant le modèle et un expert métier chargé des contenus et de la validation. Un spécialiste documentaire ou un évaluateur peut intervenir ponctuellement. Cette configuration convient à l’exploration, à condition que les limites du pilote soient explicites.

Pour un service sectoriel en exploitation, il devient utile de stabiliser les responsabilités : responsable métier, ingénieur IA ou logiciel, personne chargée du patrimoine de connaissances, responsable des tests et de la maintenance. Certaines fonctions peuvent rester externalisées, mais les procédures doivent être reproductibles.

Pour une plateforme partagée entre plusieurs organisations, des compétences avancées en architecture des connaissances, interopérabilité, gouvernance, sécurité et exploitation peuvent être nécessaires. L’organisation dépend alors aussi des droits, des niveaux de service et du financement de la maintenance.

Il n’existe pas de configuration universellement supérieure : la proportionnalité aux usages et aux risques doit guider le choix.

Pour un assistant de mathématiques, l’enseignant ou le spécialiste pédagogique précise les niveaux, les méthodes et les critères d’accompagnement. Le documentaliste qualifie les programmes, cours, exercices et corrigés. L’ingénieur des connaissances formalise les notions, les prérequis et les erreurs fréquentes lorsque cette structuration est utile.

L’ingénieur IA construit les mécanismes de recherche, de génération et de vérification. Le spécialiste de l’évaluation prépare des scénarios : réponses exactes, erreurs d’élèves, énoncés incomplets, méthodes alternatives et questions hors périmètre.

Le responsable du produit arbitre les priorités et s’assure que les corrections sont réellement intégrées. Dans une petite startup, plusieurs rôles peuvent être réunis. En revanche, la validation pédagogique ne doit pas être simplement déduite du bon fonctionnement technique du prototype.

Une difficulté récurrente des projets d’IA est la confusion des responsabilités. La personne qui transforme un document en données structurées n’est pas nécessairement habilitée à valider le sens d’une règle. Celle qui vérifie le contenu métier n’est pas toujours responsable de sa publication.

Il est utile de distinguer trois décisions : produire la ressource, contrôler sa qualité et autoriser son utilisation. Cette séparation peut être légère dans un pilote, mais elle doit rester explicite, particulièrement lorsque les conséquences d’une erreur sont importantes.

Un registre de décisions ou une matrice de responsabilités peut préciser qui approuve les sources, qui accepte les anomalies résiduelles, qui déclenche une suspension et qui valide les nouvelles versions. Il évite qu’une application soit publiée simplement parce que son développement est terminé.

Une organisation ne peut pas toujours recruter un expert pour chaque spécialité. Les profils hybrides permettent de relier une discipline métier à des méthodes d’ingénierie des connaissances et à une culture technique suffisante.

Un enseignant peut apprendre à formaliser des progressions et à construire des jeux de tests. Un documentaliste peut se spécialiser dans les corpus destinés aux architectures RAG. Un statisticien peut contribuer à la qualité des données et à l’évaluation. Un juriste peut structurer des règles et leurs conditions d’application.

Ces profils ne remplacent pas systématiquement les experts avancés. Ils rendent cependant la coopération plus fluide et permettent d’ancrer les projets dans les réalités des secteurs.

Les compétences fréquemment mobilisées et étroitement liées à la proposition de valeur peuvent justifier une capacité interne. Les expertises rares, comme certaines modélisations sémantiques complexes ou des audits spécialisés, peuvent être mobilisées ponctuellement.

La mutualisation peut concerner des outils de préparation documentaire, des méthodes de validation, des spécialistes ou des référentiels communs. Elle peut réduire certaines duplications, mais crée des obligations de coordination, de gouvernance et de financement.

Le choix doit tenir compte de la sensibilité des connaissances, des droits, du volume de travail, du coût complet et de la capacité à conserver la maîtrise du produit. Externaliser la préparation d’un corpus ne dispense pas l’organisation de définir les exigences et d’en vérifier les résultats.

Une équipe interdisciplinaire travaille mieux lorsque les échanges produisent des objets vérifiables. Le cadrage peut déboucher sur un cahier des besoins de connaissances. La collecte produit un registre de sources. La formalisation produit des fiches de notions, de règles ou de méthodes. La validation produit des décisions et des réserves documentées.

La construction technique s’accompagne de contrats d’interface et de versions identifiables. L’évaluation produit des jeux de tests, des résultats et un registre d’anomalies. La maintenance définit les responsables et les procédures de correction.

Ces livrables n’ont pas besoin d’être lourds. Leur fonction est d’éviter les malentendus entre métiers et de rendre les choix traçables.

Un intitulé prestigieux ou une liste d’outils maîtrisés ne prouvent pas qu’une équipe sait construire un service fiable. Il faut examiner les réalisations : corpus qualifiés, connaissances formalisées, contrôles documentés, résultats de tests et capacité à corriger les défaillances.

Une équipe peut être techniquement excellente et manquer de validation métier. Une autre peut disposer d’experts sectoriels sans savoir intégrer leurs connaissances dans l’application. Le diagnostic doit donc porter sur les compétences effectivement démontrées et sur les interfaces entre personnes.

Les niveaux de maîtrise proposés dans le référentiel — compréhension, pratique opérationnelle, expertise spécialisée, architecture et innovation — peuvent aider à identifier les besoins de formation. Ils ne constituent pas une certification officielle.

À l’échelle d’un pays, la question dépasse le recrutement des startups. Les administrations, universités, entreprises et laboratoires peuvent posséder des compétences complémentaires sans disposer encore de mécanismes permettant de les mobiliser ensemble.

Une stratégie de développement des capacités nationales en IA peut donc examiner les métiers existants, les spécialisations nécessaires, les dispositifs de formation par projets et les possibilités de mutualisation de certaines expertises.

Il serait toutefois prématuré de fixer des effectifs ou des filières sans diagnostic des besoins et des ressources disponibles. La cartographie des compétences constitue une grille d’analyse à confronter aux projets réels et aux pratiques professionnelles.

Construire une IA sectorielle ne consiste pas à additionner des développeurs, des experts métier et des spécialistes des données sans organiser leur coopération. Il faut relier les usages, les connaissances, la technologie, la validation et la maintenance.

La composition de l’équipe doit être proportionnée au projet, mais les responsabilités essentielles ne doivent pas rester invisibles. La capacité à formaliser les savoirs, à vérifier leur utilisation et à corriger les erreurs compte autant que la qualité de l’interface.