Partie 5 — Modèles et outils

Quatre modèles de travail portent le cadre. Aucun n’est complexe ; la valeur tient à les tenir à jour plutôt qu’au format lui-même.

Les modèles

• Registre des risques — ID, catégorie, description, probabilité (1–5), impact (1–5), score, responsable, atténuation, échéance, statut. La source unique de vérité de la partie 2.
• Journal RAID — risques, hypothèses, problèmes et dépendances suivis ensemble pour tout le projet, revus en même temps que le registre des risques pour que rien ne passe entre les mailles.
• Liste de contrôle pre-mortem — avant le lancement et avant chaque jalon, posez la question : « Dans douze mois, ce projet a échoué — pourquoi ? » Consignez chaque réponse plausible comme un risque.
• Liste de contrôle des jalons — business case validé, préparation des données confirmée, cartographie de conformité terminée, plan de gestion du changement en place, plan de retour arrière défini. Tout est requis avant de financer la phase suivante.

Outils

Aucun de ces quatre artefacts n’exige un logiciel dédié pour démarrer. Pour la plupart des déploiements à l’échelle d’une PME :

• Commencez par un seul tableur partagé. Un unique Google Sheet ou fichier Excel, un onglet par artefact — registre, journal RAID, journal pre-mortem, liste de contrôle des jalons — partagé avec le comité de pilotage de la partie 4. C’est suffisant pour toute la durée de vie d’un seul pilote.
• Passez à un outil de suivi léger (Notion, Airtable, ou votre outil de projet existant) dès que vous menez plus d’un projet d’IA à la fois, ou dès que le registre doit être filtré et recoupé par catégorie, responsable ou étape, tous projets confondus.
• Ne passez à une plateforme GRC dédiée qu’une fois le volume de risques, de fournisseurs ou de cartographies réglementaires suivis réellement ingérable dans un tableur — pour la plupart des PME que ce playbook vise, ce point n’arrive jamais.
• Quoi que vous utilisiez, une règle compte plus que l’outil : il doit s’agir de l’unique copie que le comité de pilotage ouvre réellement en direct pendant la réunion de la partie 4, pas d’une diapositive exportée à partir de celle-ci. Un registre que personne n’ouvre en direct, c’est l’échec « rédigé une fois puis classé » contre lequel la partie 2 met déjà en garde.

Exemple travaillé

Une ligne remplie par artefact, pour que les champs ne restent pas abstraits.

Registre des risques

Journal RAID

La même entrée de registre, plus :

• Hypothèse — « les données marketing sont assez propres pour éviter un audit complet » (responsable : sponsor, à tester avant le 3 oct.).
• Dépendance — le pilote ne peut pas démarrer tant que l’audit de consentement n’est pas clos.

Liste de contrôle pre-mortem

« Dans douze mois, ce projet a échoué — pourquoi ? » → réponse consignée : « Nous n’avons jamais obtenu la validation de la source de données, donc le pilote s’est enlisé à la semaine 3 en attendant le juridique. » → devient le risque R-014 ci-dessus.

Liste de contrôle des jalons (avant de financer la phase 2)

Business case validé ✓ · préparation des données confirmée ✗ (bloquée par R-014) · cartographie de conformité terminée ✓ · plan de gestion du changement en place ✓ · plan de retour arrière défini ✓. Un seul point ouvert suffit à bloquer le jalon.

Responsabilité et cadence

Chaque artefact renvoie au RACI et à la cadence de revue définis dans la partie 4.

Un registre mis à jour seulement quand quelqu’un y pense est exactement l’échec contre lequel la partie 2 met en garde — « un registre rédigé une fois puis classé est pire que pas de registre du tout ». La même discipline s’applique aux quatre artefacts ici, pas seulement au registre.

Où cela se casse

• Registre des risques utilisé comme un formulaire d’admission ponctuel au lieu d’un document vivant — rempli au lancement, jamais repris lors des revues mensuelles prévues par la partie 4.
• Journal RAID dupliqué en second registre des risques au lieu de suivre ce que le registre ne couvre pas : les hypothèses que personne n’a encore testées et les dépendances qui empêchent un risque d’être clos.
• Pre-mortem fait une fois au lancement et jamais répété — la partie 2 le prévoit avant le lancement et avant chaque jalon, mais c’est l’étape que les équipes sautent dès que l’élan rend l’échec improbable.
• Liste de contrôle des jalons traitée comme une formalité à valider mécaniquement plutôt qu’un vrai point de blocage — une case non cochée qui passe malgré tout sous la pression des délais, c’est la liste de contrôle qui échoue au moment même pour lequel elle existe.

Comment les cinq parties s’articulent

La partie 1 a nommé les sept catégories qui font dérailler les projets d’IA. La partie 2 en a fait un registre noté et vivant. La partie 3 a donné à chaque catégorie sa propre atténuation, pas une atténuation générique. La partie 4 a placé trois personnes nommées et une cadence fixe autour de l’ensemble pour qu’il ne cesse pas de tourner après la première semaine. Ces quatre artefacts sont là où tout cela vit au quotidien — le registre est celui à construire en premier, parce que tout le reste ici l’alimente ou en découle. Construisez-le, mettez-le devant le comité de pilotage de la partie 4, et le reste du cadre a un endroit où tourner.

Il se connecte aussi vers l’extérieur : le registre de gouvernance de la Série de playbooks gouvernance de l’IA est là où vit le versant conformité de ces mêmes risques, et le tableau de bord de Mesurer la valeur, le risque, les coûts et les KPI est là où vous les surveillez après la mise en service.