Avant de développer votre assistant IA, construisez son patrimoine de connaissances

Une startup imagine un assistant intelligent pour accompagner les élèves dans leurs exercices de mathématiques. En quelques jours, elle connecte une interface à un modèle de langage, ajoute la possibilité de photographier un exercice et obtient une démonstration impressionnante. L’élève pose une question ; l’application répond.

Mais lorsque les premiers utilisateurs arrivent, de nouvelles difficultés apparaissent. L’assistant emploie parfois une méthode qui ne correspond pas au niveau scolaire, confond des versions de supports pédagogiques ou donne une explication convaincante sans être exacte. Les enseignants demandent comment les réponses sont vérifiées. Les parents veulent savoir ce que l’application fait réellement pour favoriser l’apprentissage.

Ce passage du prototype au service durable révèle un chantier souvent sous-estimé : organiser les connaissances et les exigences métier dont l’application a besoin. Pour une startup, ce travail peut devenir aussi important que le choix du modèle d’IA.

Le premier réflexe ne devrait pas être de télécharger tous les PDF disponibles. Il faut définir précisément le service rendu : expliquer une notion, accompagner un exercice, corriger une réponse, identifier une difficulté ou proposer une remédiation. Ces fonctions ne nécessitent pas toutes les mêmes ressources.

Pour un premier pilote, la startup peut choisir un périmètre restreint : par exemple, un ensemble d’exercices d’équations du premier degré, à un niveau scolaire explicitement déterminé après examen du programme applicable. Elle doit préciser les situations prises en charge et celles qu’elle exclut.

Cette étape produit un cahier des besoins de connaissances. Elle permet de déterminer ce que l’assistant doit savoir, ce qu’il doit pouvoir vérifier, ce qu’il doit demander à l’utilisateur et les situations dans lesquelles il doit reconnaître ses limites.

Une application pédagogique peut s’appuyer sur des programmes officiels, des cours, des exercices, des corrigés et l’expérience des enseignants. Une application administrative mobilisera d’autres sources : textes, formulaires, procédures, critères d’éligibilité et interprétations validées.

Chaque source doit être qualifiée. Quelle est son origine ? Sa version ? Sa période de validité ? Son niveau d’autorité ? Peut-elle être extraite, stockée, indexée et utilisée dans un service commercial ? La présence d’un document sur Internet ne signifie pas que tous ces usages sont autorisés.

Un registre des sources, même simple au départ, doit conserver les références, les restrictions, les responsables de validation et les lacunes connues. Ce registre évite qu’un contenu non vérifié devienne, par glissement, une référence considérée comme officielle.

Les documents ne sont pas toujours directement exploitables. Les formules peuvent être mal extraites, les tableaux perdre leur structure, les figures être séparées des énoncés. La préparation du corpus doit préserver les informations qui donnent leur sens aux contenus.

Selon les fonctions, la startup peut ensuite créer des fiches de notions, associer les exercices à des compétences, documenter les prérequis, expliciter les méthodes de résolution ou identifier des erreurs fréquentes. Une partie de ce travail peut être assistée par l’IA, mais les propositions doivent être contrôlées.

Il ne s’agit pas de reconstruire toutes les connaissances générales déjà maîtrisées par un modèle. Il s’agit de préparer ce qui doit être contextualisé, rendu traçable, vérifié ou adapté aux exigences du produit.

Un modèle généraliste peut suffire pour certaines explications ou tâches exploratoires. Une architecture RAG peut être utile lorsque les réponses doivent s’appuyer sur un corpus de référence et citer des passages. Des données structurées peuvent être nécessaires pour filtrer les exercices selon le niveau, la notion ou le statut de validation.

Pour vérifier un calcul ou appliquer une règle déterministe, un outil spécialisé peut être plus approprié qu’une réponse purement générative. Des relations entre notions peuvent être représentées dans des fiches ou, si la complexité le justifie, dans un graphe de connaissances.

Le choix ne doit pas être dicté par la mode technologique. Il doit résulter d’une comparaison sur les cas d’usage : exactitude, coût, rapidité, facilité de maintenance, traçabilité et risques. Un système plus complexe n’est pas automatiquement meilleur.

Le développeur et l’ingénieur IA construisent l’application et les mécanismes d’accès aux modèles. Mais d’autres compétences peuvent être nécessaires : ingénierie documentaire pour qualifier les sources, ingénierie des connaissances pour formaliser les méthodes, expertise sectorielle pour valider le contenu, gouvernance pour gérer les droits et versions, évaluation pour vérifier les réponses.

Dans une startup, ces fonctions n’exigent pas huit recrutements distincts. Certaines peuvent être réunies dans une petite équipe, mobilisées auprès de partenaires ou achetées sous forme de prestations spécialisées.

L’important est de ne laisser aucune responsabilité critique sans titulaire : qui décide qu’un corrigé est exact ? Qui peut retirer une ressource erronée ? Qui examine les incidents ? Qui valide les nouvelles versions ?

Supposons que l’élève réponde x = 7 à l’équation 3x + 7 = 22. Un assistant peut simplement fournir la solution x = 5. Mais si l’objectif est l’apprentissage, il peut être préférable de demander à l’élève de vérifier sa proposition dans l’équation initiale, puis de lui offrir un indice progressif.

Ce choix n’est pas un détail d’interface. Il relève de la stratégie pédagogique. Dans d’autres secteurs, des décisions analogues concernent le moment où l’assistant doit demander une précision, signaler une incertitude ou transmettre la situation à un professionnel.

Ces comportements doivent être définis avec les experts du domaine, documentés et évalués. Un prompt bien rédigé peut aider, mais il ne remplace pas à lui seul les exigences métier ni les mécanismes de contrôle.

Une base de connaissances correcte ne garantit pas une réponse correcte. Le système peut retrouver le mauvais document, ignorer une condition, utiliser une version obsolète ou produire une conclusion non justifiée.

La startup doit construire un jeu de tests représentatif : situations normales, erreurs fréquentes, demandes ambiguës, ressources absentes, méthodes alternatives correctes et questions hors périmètre. Les résultats attendus doivent être définis avant l’exécution des tests.

Il faut distinguer les défauts de source, de structuration, de recherche, de génération et de comportement métier. Cette analyse évite de corriger un problème documentaire uniquement en modifiant les consignes du modèle.

Les tests doivent aussi tenir compte des risques propres au domaine. Pour un assistant destiné à des mineurs, la protection des données, l’adéquation des interactions et les limites de l’assistance sont des exigences centrales.

Les programmes, notions, exercices et méthodes pédagogiques peuvent constituer un patrimoine de connaissances partagé, sous réserve des droits applicables. L’historique d’un élève, ses réponses et ses résultats d’apprentissage relèvent d’une autre catégorie de données.

Ces données individuelles exigent une protection adaptée, des règles d’accès et des finalités clairement définies. Leur collecte ne doit pas être présumée nécessaire simplement parce que l’application dispose d’un modèle d’IA.

La séparation entre ressources communes et données personnelles facilite la gouvernance, la sécurité et la possibilité de réutiliser le patrimoine pédagogique dans plusieurs applications.

Un programme scolaire peut être révisé ; un corrigé peut contenir une erreur ; une nouvelle version du modèle peut modifier les comportements de l’assistant. Le patrimoine de connaissances doit donc pouvoir évoluer.

Chaque ressource importante devrait disposer d’un identifiant, d’une version, d’un statut de validation et d’un responsable. La startup doit prévoir comment corriger, suspendre, remplacer et republier les contenus, puis vérifier l’absence de régression.

Cette maintenance représente un coût récurrent. Un budget qui ne couvre que le développement initial de l’application risque de sous-estimer l’effort nécessaire pour maintenir un service fiable.

Un patrimoine bien structuré, juridiquement exploitable, validé et maintenable peut soutenir plusieurs produits. Une startup éducative pourrait réutiliser certaines ressources dans un assistant, une plateforme d’exercices ou un outil pour enseignants, sans confondre leurs fonctionnalités ni leurs données utilisateurs.

Cet actif ne constitue pas automatiquement une barrière à l’entrée ni un avantage concurrentiel durable. Sa valeur dépend notamment de sa qualité, de ses droits, de son coût d’entretien, de son utilité et de la possibilité de le réutiliser.

Pour les investisseurs, les questions pertinentes ne portent donc pas uniquement sur la démonstration du modèle : la startup maîtrise-t-elle ses sources ? Peut-elle prouver la qualité des réponses ? Connaît-elle ses coûts de maintenance ? Ses ressources sont-elles réellement différenciantes ?

Pour éviter de transformer le projet en chantier documentaire interminable, une startup peut organiser un pilote limité autour de six productions vérifiables. Le premier est un cahier des usages et des limites. Le deuxième est un registre de sources autorisées et qualifiées. Le troisième est un petit corpus ou référentiel de connaissances structuré.

Le quatrième est une description des comportements attendus de l’assistant. Le cinquième est un jeu de tests accompagné de ses critères d’acceptation. Le sixième est un dossier de maintenance précisant les versions, les responsabilités et les corrections.

Ces livrables peuvent être légers. Ils servent à rendre le travail contrôlable et reproductible, non à imposer une bureaucratie à une jeune entreprise.

Après le pilote, l’équipe pourra décider, sur la base des résultats, d’étendre le périmètre, de changer d’architecture, de renforcer les expertises ou de renoncer à certaines fonctionnalités.

Une startup peut aujourd’hui accéder rapidement à un modèle d’IA puissant. Cette facilité d’accès est une opportunité considérable, mais elle ne supprime pas les exigences propres à la construction d’un service sectoriel fiable.

Le produit se construit aussi à travers les connaissances qu’il mobilise, les professionnels qui les préparent, les méthodes qui encadrent son comportement et les tests qui vérifient son utilité.

Avant de chercher à enrichir indéfiniment son assistant de nouvelles fonctionnalités, une startup gagnera donc à se poser une question structurante : de quelles connaissances notre service dépend-il, et comment allons-nous en garantir la qualité dans la durée ?