Identifier les risques

Ce que l'IA fait bien ici, ce qu'elle fait mal

Ce qu'elle fait bien

• Partir des documents du projet: le modèle rend en quelques minutes une première liste de risques à trier.
• Suivre une forme imposée: quand le prompt l'exige, chaque ligne porte sa cause, son événement et son effet.
• Citer sa source: quand le prompt l'exige, chaque cause porte un passage que le chef de projet peut retrouver.
• Varier les pistes: le modèle propose des modes de défaillance et des mesures au-delà des premières idées de l'équipe.
• Questionner les lacunes: le modèle liste ce que les documents ne disent pas et le rôle à interroger.
• Récrire une liste en vrac: le modèle reformule en cause, événement et effet les risques notés pendant une séance.

Ce qu'elle fait mal

• Connaître votre projet: sans les documents du projet, le modèle rend des risques qui valent pour tout projet.
• Voir ce que les documents taisent: un fournisseur, une personne indispensable ou une donnée manque à la liste.
• Écrire l'effet: sans consigne, une ligne se réduit souvent à un mot comme «budget» ou «délais».
• Séparer risque et fait: le modèle écrit en risque un fait acquis ou un problème déjà survenu.
• Citer exactement: le modèle peut attribuer aux documents une phrase qui n'y figure pas.
• Noter les risques: le modèle attribue une probabilité et un impact que rien dans les documents ne fonde.
• Juger de la complétude: une longue liste classée paraît complète même quand un domaine entier manque.
• Rendre la même liste: relancé sur les mêmes documents, le modèle rend d'autres risques avec d'autres libellés.

Déroulé

Le PMBOK Guide décrit l'identification des risques comme un processus de la gestion des risques (huitième édition, 2.7.2.2). Le processus relève les menaces et les opportunités. Il sépare les risques des préoccupations et des problèmes. La figure 2-49 range l'intelligence artificielle parmi les outils de ce processus à côté du brainstorming, des entretiens et de l'analyse documentaire. Le PMBOK ne décrit pas de méthode pour cet outil. Le modèle lit le périmètre et le planning que le chef de projet a ébauchés selon la page Ébaucher la WBS et le planning. Les risques tirés des bilans de projets passés relèvent de la page Les leçons apprises. Les risques d'un système d'IA relèvent de la page Évaluer les risques de l'IA.

Un énoncé de risque sépare la cause, l'événement et l'effet. La cause est un fait qui vaut aujourd'hui. L'événement est incertain. L'effet touche un objectif du projet: le délai, le coût, la qualité ou le périmètre. Le PMBOK propose cet énoncé structuré pour distinguer le risque de ses causes et de ses effets (section 4, registre des risques). David Hillson l'écrit en une phrase: «En raison de [cause], [événement] peut survenir, ce qui entraînerait [effet].» Le BABOK emploie la forme «Si [événement], alors [conséquence]» (10.38). Les deux formes obligent à écrire l'effet.

1. Le chef de projet rassemble les documents du projet. Le modèle reçoit le mandat de projet, l'énoncé du périmètre avec ses exclusions, la WBS, le planning et le journal des hypothèses. Le PMBOK compte le périmètre, le planning et le journal des hypothèses parmi les entrées de l'identification. Le chef de projet remplace les noms de personnes et de clients par des rôles. Un résumé de trois lignes produit une liste de risques génériques.
2. Le modèle rédige les énoncés. Le prompt de l'étape 2 impose la forme cause, événement, effet. Il demande de citer mot pour mot, pour chaque cause, le passage des documents qui l'établit. Une cause sans passage porte la mention «sans source». Le modèle classe chaque risque en menace ou en opportunité. Il ne note ni la probabilité ni l'impact.
3. Le chef de projet trie la liste. Il retrouve chaque citation dans les documents. Une citation introuvable est une hallucination: la ligne perd sa cause et passe en «sans source». Pour chaque ligne, il se demande si la cause vaut aujourd'hui dans ce projet, si l'événement est encore incertain et si l'effet touche un objectif nommé. Un fait acquis passe au journal des hypothèses ou devient la cause d'un autre énoncé. Un problème déjà survenu passe au journal des problèmes. Une ligne «sans source» reste seulement si le chef de projet lui trouve une cause dans ce projet. La fiche Analyse des causes racines aide à remonter d'un effet à sa cause.
4. Le modèle liste ce que les documents ne disent pas. Le chef de projet ouvre une nouvelle conversation avec le prompt de l'étape 4, les documents du projet et la liste triée. Le prompt demande des questions sur les données, les fournisseurs, les personnes indispensables, les dates imposées et les règles dont un risque dépend. Chaque question nomme le rôle qui peut répondre. Le modèle ne répond à aucune question: sa réponse aurait l'air d'un fait. La page Les chaînes de prompts explique pourquoi chaque maillon garde une seule tâche. Vous trouverez dans la fiche Analyse documentaire pourquoi un modèle ne rapporte pas ce qu'on ne lui a pas donné.
5. Les parties prenantes répondent. Le chef de projet pose les questions en entretien ou en atelier. Quand une réponse révèle une cause, le chef de projet en écrit l'énoncé dans la même forme. Quand une réponse contredit un document, il corrige d'abord le document ou le journal des hypothèses. Il écrit ensuite l'énoncé. Une séance de brainstorming peut partir de la liste triée.
6. L'équipe évalue les risques et le chef de projet nomme leurs propriétaires. L'équipe fixe la probabilité, l'impact et la priorité avec les échelles du plan de gestion des risques. Le modèle n'intervient pas dans cette étape. La fiche Analyse et gestion des risques explique pourquoi l'estimation reste aux parties prenantes. L'annexe X3 du PMBOK prête à l'IA l'estimation de la probabilité et de l'impact. Cette estimation vient d'une analyse prédictive des données de projets passés. Un modèle de langage qui lit les documents du projet n'a aucun historique dont tirer une note. La page Familles de capacités et modalités sépare prédire et générer. Le PMBOK fait de l'identification un processus itératif. Le chef de projet reprend le déroulé à chaque changement du plan.

Prompt modèle

Étape 2: rédiger les énoncés

Tu es chef de projet. Tu prépares une première liste de risques pour [PROJET ET ORGANISATION].

<documents>
[DOCUMENTS DU PROJET]
</documents>

<objectifs>
[OBJECTIFS DU PROJET]
</objectifs>

<consignes>
1. Relève les risques du projet: les menaces et les opportunités.
2. Écris chaque risque en trois champs: Cause, Événement, Effet. La cause est un fait qui vaut aujourd'hui. L'événement est incertain. L'effet touche un objectif de <objectifs>.
3. Pour chaque cause, cite mot pour mot le passage de <documents> qui l'établit. Si aucun passage ne l'établit, écris «sans source».
4. Indique si le risque est une menace ou une opportunité.
5. Liste à part les faits acquis et les problèmes déjà survenus que tu as trouvés avec leur passage.
6. N'attribue aucune probabilité et aucun impact. Ne propose aucun propriétaire.
7. Rends un tableau: identifiant (R1, R2…), cause, événement, effet, objectif touché, menace ou opportunité, passage cité.
</consignes>

• [PROJET ET ORGANISATION] situe le domaine et le vocabulaire attendu.
• [DOCUMENTS DU PROJET] reçoit les documents rassemblés à l'étape 1.
• [OBJECTIFS DU PROJET] liste les objectifs mesurables: la date de mise en service, le budget, le niveau de qualité attendu.

Étape 4: questionner ce que les documents ne disent pas

Tu relis la liste de risques d'un projet avec les documents du projet.

<documents>
[DOCUMENTS DU PROJET]
</documents>

<risques>
[LISTE TRIÉE]
</risques>

<consignes>
1. Relève ce dont un risque pourrait dépendre et que <documents> ne décrit pas: les données à reprendre, les fournisseurs et leurs ressources, les personnes indispensables et leur disponibilité, les dates imposées de l'extérieur, les règles légales et contractuelles.
2. Formule chaque point comme une question. Nomme le rôle qui peut y répondre.
3. Ne réponds à aucune question. N'ajoute aucun risque.
4. Rends un tableau: numéro (Q1, Q2…), question, rôle à interroger, risques de <risques> concernés ou «aucun».
</consignes>

• [LISTE TRIÉE] reçoit les lignes que le chef de projet a gardées à l'étape 3.
• [DOCUMENTS DU PROJET] reprend mot pour mot le texte de l'étape 2.

Le gouvernement britannique publie un prompt de registre des risques dans son AI Knowledge Hub. Ce prompt demande lui aussi un descriptif du projet et rappelle de vérifier chaque résultat. Ne collez dans un service d'IA que les documents que votre organisation autorise à y envoyer.

Exemple

Une fiduciaire lausannoise de 35 personnes remplace son logiciel de gestion des mandats. Le chef de projet a donné au modèle l'énoncé du périmètre, la WBS approuvée et son dictionnaire. Ces documents fixent la mise en service au 1er juin 2026. Le support de l'ancien logiciel prend fin le 30 juin. Le fournisseur extrait les 1'200 mandats actifs et la responsable des mandats contrôle la reprise. Le fournisseur forme quatre utilisateurs clés. Ceux-ci forment les autres collaborateurs. Le remplacement du logiciel comptable est exclu.

Le modèle a rendu sept lignes. Le chef de projet les a triées. Les énoncés de R1 à R3 sont abrégés. Les réponses aux questions de l'étape 4 ont donné R8 et R9.

Le modèle a trouvé R4 à R7 dans les documents. R7 est une opportunité: elle réduit la menace R4. R1 et R2 vaudraient pour n'importe quel projet. R3 décrit une date certaine: le chef de projet l'a reportée comme échéance dans l'effet de R4. Q2 demandait quels champs de l'ancien logiciel l'extraction standard ne reprend pas. La responsable des mandats a répondu que 140 mandats portent leurs conventions d'honoraires en texte libre. Q4 demandait combien de personnes du fournisseur savent faire l'extraction. Le fournisseur a répondu qu'une seule le sait. Aucun passage des documents ne contenait ces deux faits. Le modèle a posé les questions et les parties prenantes ont fourni les causes. L'équipe a évalué les six risques gardés et le chef de projet leur a donné un propriétaire.

Vérifier le résultat

• Le modèle a-t-il reçu les documents du projet plutôt qu'un résumé de quelques lignes?
• Les noms de personnes et de clients ont-ils été retirés avant l'envoi?
• Chaque ligne sépare-t-elle la cause, l'événement et l'effet?
• Chaque effet touche-t-il un objectif nommé du projet?
• Chaque citation se retrouve-t-elle mot pour mot dans les documents?
• Chaque ligne «sans source» a-t-elle reçu une cause propre au projet ou a-t-elle été écartée?
• Les faits acquis et les problèmes déjà survenus sont-ils sortis de la liste des risques?
• La liste contient-elle des opportunités?
• Chaque question du modèle a-t-elle reçu la réponse du rôle qu'elle nomme?
• La probabilité et l'impact viennent-ils de l'équipe et des échelles du plan de gestion des risques?
• Chaque risque a-t-il un propriétaire?

Limites et risques

Les documents du projet contiennent des données personnelles. Le nom d'un collaborateur ou d'un client personne physique est une donnée personnelle (art. 5 let. a LPD). Le nom d'un fournisseur, les montants et les clauses de contrat relèvent de la confidentialité. Le fournisseur d'un service d'IA agit comme sous-traitant quand un contrat le lie à l'organisation: l'art. 9 LPD exige ce contrat ou une base légale. Si le fournisseur traite les données hors de Suisse, l'art. 16 soumet cette communication à une décision d'adéquation du Conseil fédéral ou à des garanties. Le chef de projet remplace les noms de personnes par des rôles et utilise le service que son organisation a évalué. La page «La LPD et les données confidentielles» traite ce cadre.

La liste reste générique. Collier et ses coauteurs ont soumis à ChatGPT l'évaluation des risques de six produits de consommation. Des professionnels de la sécurité des produits ont noté les réponses. Le modèle réussissait mieux à proposer des modes de défaillance et des mesures qu'à rédiger des conseils pour les concepteurs, les utilisateurs et les autorités. Ces conseils paraissaient trop génériques et parfois extravagants. Ils restaient loin de la connaissance d'un expert. Certains résultats contenaient des erreurs et des incohérences. D'autres modèles de langage montraient le même profil. L'étude porte sur la sécurité des produits. Sur un projet, la même tendance au générique s'explique: le modèle complète les documents reçus par ce que les projets de ce type contiennent d'habitude. Le risque propre au projet vient des personnes qui le connaissent. Les questions de l'étape 4 les font parler.

La responsabilité reste au chef de projet. Il répond du registre devant le mandant. Il conserve les prompts et les réponses du modèle et des parties prenantes. Il ajoute au registre une colonne Origine. Elle donne pour chaque risque le passage cité ou la réponse qui fonde sa cause.

Techniques liées

• Analyse et gestion des risques: le registre, les échelles et l'évaluation que le modèle laisse à l'équipe.
• Analyse des causes racines: la remontée d'un effet à la cause qu'un énoncé doit nommer.
• Brainstorming: la séance humaine qui part d'une liste produite par un modèle.
• Entretien: les questions qui trouvent ce que les documents ne disent pas.
• Analyse documentaire: la lecture critique du mandat, du périmètre et du planning.
• Analyse SWOT: une seconde lecture du projet par ses forces, ses faiblesses, ses opportunités et ses menaces.
• AMDEC: les modes de défaillance d'un périmètre technique.
• Ébaucher la WBS et le planning: le périmètre et le plan que le modèle lit.
• Les chaînes de prompts: un appel par tâche et un contrôle entre deux appels.
• Les hallucinations: la citation plausible qui ne figure pas dans la source.