IA et data : retour d’XP sur la suggestion de profils

L’intelligence artificielle bénéficie aujourd’hui d’un engouement sans précédent. Dans de nombreuses organisations, elle est encore parfois perçue comme une “brique magique” que l’on pourrait connecter à un système existant pour en démultiplier instantanément la valeur. Cette vision, largement alimentée par les démonstrations spectaculaires des modèles génératifs, masque pourtant une réalité bien plus exigeante.

Déployer une IA dans une solution métier n’est pas un sujet d’algorithme. C’est un sujet d’architecture, de qualité de la donnée, de flux, et surtout d’intégration dans des processus métier existants. Autrement dit : un sujet de SI avant d’être un sujet de Data Science.

On vous partage un retour d’expérience dans cet article.

À travers la refonte d’un moteur de suggestion basé sur plus de 15 ans de données de recrutement, un constat s’impose. La performance réelle d’un système de matching repose très largement sur deux piliers souvent sous-estimés : la qualité des données et leur exploitation dans les usages métier. L’algorithme, aussi sophistiqué soit-il, n’en constitue que la partie visible.

“Garbage In, Garbage Out”

L’un des biais les plus fréquents consiste à penser qu’un algorithme avancé, notamment basé sur du NLP (Natural Language Processing = traitement automatique du langage naturel), serait capable de compenser une base de données imparfaite. En pratique, c’est l’inverse : plus l’algorithme est sophistiqué, plus il est dépendant de la qualité de ses données d’entrée.

Dans un système de matching, tout repose sur la capacité à établir des correspondances entre deux entités : ici des besoins et des profils. Si ces entités sont mal décrites, incomplètes ou hétérogènes, le système n’a tout simplement pas la matière nécessaire pour produire des résultats pertinents.

Ce principe, souvent résumé par “Garbage In, Garbage Out”, n’est pas une abstraction théorique. Il devient un enjeu opérationnel concret dès lors que les utilisateurs finaux (recruteurs, commerciaux, managers) sont responsables de la saisie.

L’un de nos enseignements majeurs a été de déplacer le sujet de la qualité de la donnée depuis la Data Science vers l’interface utilisateur. Autrement dit : faire du SI un acteur actif de la qualité des données.

Plutôt que de laisser l’algorithme produire silencieusement des suggestions médiocres, le système doit expliciter la qualité de ses entrées. Cela passe par la mise en place d’indicateurs de complétude visibles, capables de signaler immédiatement à l’utilisateur ce qui manque pour améliorer les résultats. Cette approche transforme un problème technique en levier pédagogique.

Il est également crucial de distinguer deux notions souvent confondues : la qualité de la donnée et la pertinence du résultat. Une fiche parfaitement complétée ne garantit pas des suggestions parfaites, mais une fiche incomplète garantit presque toujours un mauvais résultat. Cette asymétrie doit être comprise et intégrée dans la conception du produit… et son utilisation.

Architecture système : de la recherche sémantique à l’intelligence métier

Historiquement, les systèmes de recherche reposaient sur des approches booléennes : l’utilisateur formulait explicitement une requête, et le système retournait des résultats correspondants. Cette logique, bien que robuste, présente deux limites majeures : elle dépend fortement de la capacité de l’utilisateur à formaliser son besoin, et elle reste prisonnière d’une logique de mots-clés.

Le passage à un moteur de suggestion nous a permis de changer radicalement le paradigme. Le système ne répond plus à une requête, il en déduit une implicitement à partir du contenu disponible. Cela nécessite une architecture capable de comprendre le sens des données, et pas seulement leur forme.

La première brique repose sur des techniques de traitement du langage naturel capables d’analyser des contenus textuels hétérogènes, dans plusieurs langues. Cette compréhension sémantique permet de dépasser les simples correspondances lexicales.

Mais la véritable rupture se situe ailleurs : dans l’exploitation de la donnée historique métier. En s’appuyant sur des milliers de processus de recrutement passés, le système apprend non seulement ce qui se ressemble, mais surtout ce qui fonctionne.

Cette distinction est fondamentale. Un bon matching n’est pas nécessairement une correspondance parfaite entre deux descriptions. C’est une probabilité de succès dans un contexte donné. C’est ce qui permet, par exemple, de suggérer des transitions de carrière pertinentes qui ne seraient jamais identifiées par une recherche classique.

Cette approche transforme le moteur en un système d’intelligence métier, capable d’intégrer des logiques statistiques issues de l’expérience collective.

Sur le plan technique, cela pose des enjeux forts de performance et de scalabilité. Le système doit être capable d’analyser plusieurs milliers de profils en quelques secondes, tout en intégrant des traitements complexes. Le temps de réponse devient ici un critère critique d’adoption : au-delà de quelques secondes, l’utilisateur perçoit le système comme lent, voire inutilisable.

Enfin, l’architecture doit être résiliente face aux données imparfaites. L’intégration de modèles capables d’inférer certaines informations manquantes (comme la localisation à partir de champs textuels) illustre cette capacité d’adaptation. Ce type de mécanisme ne remplace pas la donnée structurée, mais permet de limiter les effets de bord.

Intégration opérationnelle : redonner le contrôle aux utilisateurs

Un projet d’IA ne réussit pas parce qu’il est performant. Il réussit parce qu’il est utilisé.

Or, l’un des principaux freins à l’adoption réside dans la perception même de l’IA. Présentée comme une solution “intelligente”, elle génère des attentes irréalistes. Lorsqu’elle ne répond pas parfaitement, elle déçoit. Lorsqu’elle surprend, elle est perçue comme opaque.

Un changement apparemment anecdotique s’est révélé structurant : remplacer la notion de “matching IA” par celle de “suggestions de profils”. Ce choix de vocabulaire repositionne l’outil comme un assistant, et non comme un décideur. Il redonne à l’utilisateur son rôle central.

L’intégration dans le SI doit ensuite permettre à cet utilisateur de garder le contrôle. Cela passe notamment par la possibilité de paramétrer finement les critères de recherche. Un algorithme figé, même performant, finit toujours par générer de la frustration. À l’inverse, un système configurable permet de s’adapter à la diversité des contextes métier.

La capacité à sauvegarder des filtres personnalisés est ici un levier clé. Elle permet d’inscrire l’outil dans des routines de travail, plutôt que dans des usages ponctuels.

L’expérience utilisateur joue également un rôle déterminant. Un système qui “travaille en silence” est perçu comme défaillant. L’ajout d’indicateurs de chargement, même simples, nous a permis de rendre visible l’activité du système et de réduire la frustration.

Enfin, l’intégration doit rester non intrusive. Tous les utilisateurs n’ont pas besoin de passer systématiquement par le moteur IA. La possibilité de masquer ou de replier le composant permet de respecter cette diversité d’usages.

Ces choix relèvent moins de la technologie que de la compréhension fine des opérations. Ils illustrent un point clé : une IA utile est avant tout une IA bien intégrée.

Gouvernance, sécurité et amélioration continue

Dès lors qu’un système d’IA manipule des données sensibles, en particulier dans un contexte RH, les enjeux de gouvernance deviennent centraux.

L’un des principes fondamentaux consiste à dissocier :

• L’apprentissage des modèles d’une part,
• Les données individuelles de l’autre.

L’entraînement repose sur des données anonymisées, permettant d’identifier des tendances globales sans exploiter d’informations personnelles. Cette approche garantit la conformité avec les exigences réglementaires européennes, tout en préservant la valeur métier des données.

Mais la gouvernance ne se limite pas à la conformité. Elle englobe également la capacité du système à évoluer dans le temps.

Un moteur de suggestion n’est jamais “terminé”. Il s’inscrit dans une boucle d’apprentissage continue, alimentée par les usages. Chaque action utilisateur (compléter une fiche, ignorer une suggestion, valider un positionnement) devient un signal exploitable pour améliorer le système.

Cette logique transforme le produit en système vivant. Elle nécessite des infrastructures capables de collecter, traiter et réinjecter ces données de manière maîtrisée.

Enfin, la roadmap technique joue un rôle clé dans la pérennité du système. L’évolution vers des modèles de données plus structurés, notamment sur la dimension géographique, en est une illustration concrète. Nous travaillons au passage d’une logique déclarative (“Paris”, “France”) à un système de géocodage basé sur des coordonnées afin d’ouvrir la voie à des requêtes beaucoup plus fines. Il devient possible de raisonner en distance réelle, d’intégrer des contraintes de mobilité, et d’améliorer significativement la pertinence des suggestions.

Ce type d’évolution n’est pas un simple ajout fonctionnel. C’est une transformation du modèle de données, et donc du système lui-même.

À retenir

Le déploiement d’une IA de suggestion de profils révèle une réalité souvent contre-intuitive : la performance ne dépend pas principalement de l’algorithme.

Elle dépend de la qualité des données, de leur structuration, de leur gouvernance, et de leur intégration dans les processus métiers. Elle dépend de la capacité du système d’information à rendre ces données exploitables, compréhensibles et actionnables.

L’IA n’est pas une surcouche magique. C’est une brique profondément dépendante du SI dans lequel elle s’insère.

Les organisations qui réussiront ne seront pas celles qui auront les meilleurs modèles. Ce seront celles qui auront su construire des systèmes capables de produire, maintenir et activer de la donnée de qualité, tout en plaçant l’utilisateur au cœur du dispositif.

En d’autres termes : celles qui auront compris que l’intelligence ne se situe pas uniquement dans l’algorithme, mais dans l’ensemble du système qui le rend utile.

‍