Quand l’IA invente au lieu de chercher
Les chefs de projet qui ont testé un assistant IA pour des questions méthodologiques connaissent le scénario: une réponse structurée, rédigée avec aplomb, qui se révèle partiellement ou totalement inventée. Ce phénomène s’appelle une hallucination en terminologie IA, c’est-à-dire une réponse produite avec une grande confiance apparente mais sans ancrage factuel vérifié.
Le problème tient à l’architecture même des LLM (Large Language Models, grands modèles de langage). Ces systèmes génèrent du texte en calculant des probabilités de séquences de mots. Ils ne disposent d’aucun mécanisme interne pour distinguer un fait avéré d’une construction plausible. Lorsqu’un LLM cite un article du PMBOK qui n’existe pas ou décrit un processus HERMES en mélangeant deux phases, il ne ment pas au sens strict: il produit la suite de mots la plus probable compte tenu de son entraînement.
Pour un professionnel qui s’appuie sur ces réponses pour prendre des décisions, la nuance importe peu. Le résultat est le même: de l’information erronée intégrée dans des livrables projet.
Le mécanisme qui ancre l’IA dans le réel
Le RAG (Retrieval-Augmented Generation) désigne une architecture qui ajoute une étape de recherche documentaire avant la génération de texte. Au lieu de répondre uniquement à partir de ce qu’il a appris pendant son entraînement, le système interroge d’abord une base de connaissances (knowledge base), un ensemble structuré de documents sélectionnés et indexés, puis construit sa réponse en s’appuyant sur les passages retrouvés.
Cette approche change fondamentalement la nature des réponses, qui deviennent à la fois traçables puisque le système peut indiquer les documents sources, actualisables puisque l’ajout d’un nouveau document dans la base suffit à enrichir les réponses sans réentraîner le modèle, et contrôlables par l’organisation elle-même, ce qui répond aux exigences de souveraineté des données, un point particulièrement sensible en Suisse.
Concrètement, le processus se décompose en trois temps: le système découpe d’abord les documents en segments indexés, puis identifie les passages les plus pertinents par rapport à la question posée, avant de les transmettre au modèle de langage comme contexte de génération. Le modèle ne puise plus dans sa mémoire statistique mais dans des documents vérifiables.
Quatre cas d’usage pour les équipes projet
Le premier cas d’usage est l’assistant méthodologique. Un système RAG connecté au guide PMBOK ou à la documentation HERMES peut répondre aux questions sur les processus, les rôles ou les artefacts en citant les passages pertinents. Pour une équipe qui adopte un nouveau référentiel, c’est un gain de temps considérable par rapport à la recherche manuelle dans des documents de plusieurs centaines de pages.
Le deuxième concerne la capitalisation des retours d’expérience. Les bilans de projet et registres de leçons apprises s’accumulent dans la plupart des organisations sans jamais être réexploités. Connecter ces documents à un assistant RAG les transforme en ressource interrogeable, capable de faire remonter les enseignements d’un projet similaire au moment où l’équipe en a besoin: en phase d’initiation.
Le troisième touche au support documentaire quotidien. Cahiers des charges, études de faisabilité, comptes rendus de comité de pilotage: autant de documents que les membres d’équipe consultent rarement parce qu’ils sont difficiles à retrouver ou à parcourir. Le RAG permet de les interroger en langage naturel, ce qui abaisse le seuil d’accès à l’information projet.
Le quatrième, souvent sous-estimé, est l’aide à la rédaction de livrables. Un assistant qui peut retrouver la formulation utilisée dans des documents précédents, les standards de l’organisation ou les exigences contractuelles du projet en cours réduit le risque d’incohérence entre documents.
Les bonnes questions face à un éditeur
Le PMI estime que seuls 20% des professionnels du management de projet possèdent une maîtrise suffisante des outils d’IA. Ce chiffre traduit un décalage entre la multiplication des offres “AI-powered” et la capacité des organisations à les évaluer avec discernement.
Lorsqu’un éditeur présente un assistant IA intégré à son outil de gestion de projet, cinq questions méritent d’être posées. Sur quelles données le système génère-t-il ses réponses? La base de connaissances est-elle alimentée par les documents de l’organisation ou par un modèle générique? Les réponses indiquent-elles leurs sources? Les données transitent-elles par des serveurs hors de la juridiction de l’organisation? L’outil permet-il de contrôler quels documents sont indexés et lesquels ne le sont pas?
Un éditeur incapable de répondre clairement à ces questions commercialise probablement un LLM générique habillé d’une interface projet. L’absence de mécanisme RAG, ou son opacité, constitue un signal d’alerte que le chef de projet doit prendre au sérieux dans sa grille d’évaluation.
Des limites à garder en tête
Le RAG améliore la fiabilité mais ne la garantit pas. Un système connecté à une base documentaire incomplète ou mal structurée produira des réponses partielles. Un système dont les documents n’ont pas été mis à jour depuis six mois risque de fournir des informations obsolètes avec la même assurance qu’une réponse actualisée.
La responsabilité de vérification reste entièrement humaine. Le chef de projet qui utilise un assistant RAG pour préparer un registre des risques ou rédiger un plan de management doit valider les réponses obtenues, en particulier lorsque ces réponses alimentent des décisions engageant des ressources ou des délais. Le RAG rend l’IA plus utile en gestion de projet, à condition de ne pas confondre “plus fiable” avec “infaillible”.