Accueil › Registre RAID

Registre RAID : définition, modèle et exemple pour piloter votre projet

Guide pratique pour chefs de projet et PMO · Mis à jour le 8 octobre 2026 · 8 min de lecture

Un registre RAID est le tableau où vous gardez, au même endroit, tout ce qui peut faire dérailler un projet ou doit le faire avancer : les risques, les actions, les problèmes (issues) et les décisions. Bien tenu, il évite les mauvaises surprises en comité de pilotage. Voici comment le construire, avec un modèle à télécharger.

Que signifie RAID ?

RAID est un sigle de quatre lettres. Il existe deux variantes courantes, et il est utile de savoir laquelle votre organisation utilise avant d'ouvrir un tableau :

Les deux servent le même objectif : ne rien laisser « dans la tête de quelqu'un ». La variante classique insiste sur ce que vous supposez et ce dont vous dépendez. La variante pilotage insiste sur ce qu'il faut faire et ce qui a été tranché, ce qui est plus pratique pour animer un point hebdomadaire. Si votre PMO impose l'une des deux, suivez-la ; sinon, choisissez celle qui colle à vos réunions.

Risque, problème, action, décision : la différence

La confusion la plus fréquente est entre risque et problème. La règle est simple : un risque n'est pas encore arrivé, un problème est déjà là.

• Risque : un événement possible, incertain, qui aurait un effet sur le projet. « Le prestataire pourrait livrer en retard. » On l'évalue (probabilité, impact) et on prévoit une parade.
• Problème (issue) : un risque qui s'est réalisé, ou une difficulté déjà présente. « Le prestataire a livré avec trois semaines de retard. » On ne l'évalue plus : on le résout.
• Action : quelque chose à faire, par quelqu'un, avant une date. Elle découle souvent d'un risque (parade) ou d'un problème (correction).
• Décision : un choix acté, avec sa date, la personne qui l'a pris et ses conséquences. Les décisions évitent de rediscuter trois mois plus tard de ce qui a déjà été tranché.

Que renseigner pour chaque élément

Un registre efficace est court : trop de colonnes, et personne ne le remplit. Voici le minimum utile pour chaque type.

Un conseil qui change tout : rédigez chaque risque en une phrase du type « à cause de X, il se pourrait que Y arrive, ce qui entraînerait Z ». « Retard possible » ne dit rien ; « à cause de la disponibilité limitée de l'équipe infrastructure, la recette pourrait démarrer avec deux semaines de retard, ce qui décalerait la mise en production » se traite.

Évaluer la criticité d'un risque

Pour savoir quels risques traiter en premier, croisez deux questions : quelle est la probabilité que cela arrive ? et quelle serait la gravité si cela arrivait ? Une échelle à trois niveaux (faible, moyenne, élevée) suffit dans la plupart des projets. En donnant 1, 2 ou 3 à chaque niveau, la criticité est le produit des deux :

• Score de 6 à 9 (rouge) : risque critique. Il doit avoir un plan de mitigation, un responsable nommé et être présenté au comité de pilotage.
• Score de 3 à 4 (orange) : à surveiller et à traiter si possible. Revu chaque semaine.
• Score de 1 à 2 (vert) : accepté ou simplement suivi.

Cette notation est un outil de tri, pas une science exacte : l'essentiel est que toute l'équipe évalue de la même façon, d'une revue à l'autre.

Exemple de registre RAID

Voici un extrait pour un projet fictif de migration d'un outil de relation client :

Remarquez que la décision D-01 répond au risque R-01 : c'est tout l'intérêt de garder ces éléments dans un seul registre, avec des liens entre eux.

Les erreurs les plus fréquentes

1. Le registre n'est jamais relu. Un registre rempli au lancement puis oublié est pire que pas de registre : il donne une fausse impression de maîtrise.
2. Des risques trop vagues. « Retard possible » ne se traite pas. Décrivez la cause, l'événement et l'effet.
3. Pas de responsable. Un risque sans nom en face n'appartient à personne, donc personne ne le traite.
4. Confondre risque et problème. Quand un risque se réalise, passez-le en problème et ouvrez les actions correctives.
5. Pas de plan de mitigation. Lister sans prévoir de parade, c'est seulement s'inquiéter à voix haute.
6. Ne jamais clôturer. Un registre qui ne fait que grossir devient illisible. Fermez ce qui est traité ou n'est plus pertinent.
7. Oublier les décisions. C'est la partie la plus utile en cas de désaccord ultérieur, et la plus souvent négligée.

À quel rythme le mettre à jour

• Chaque semaine : 15 minutes en point d'équipe pour revoir les actions échues, réévaluer les risques rouges et orange, et ajouter les nouveautés.
• Avant chaque comité de pilotage : extraire les risques critiques et les décisions attendues. C'est ce que le sponsor veut voir, pas le registre entier.
• À chaque jalon : un nettoyage complet, avec clôture des éléments obsolètes.

Excel ou outil dédié ?

Pour un petit projet, un tableur suffit largement, et le modèle ci-dessus vous permet de démarrer en cinq minutes. Ses limites apparaissent quand le projet grandit : la matrice de criticité se recalcule à la main, les versions du fichier circulent par email, et rien ne relie un risque à la tâche du planning qu'il menace.

C'est pour ce cas que le registre RAID de Jalonis existe. Il reprend la variante « pilotage » décrite plus haut :

• quatre onglets : risques, actions, issues et décisions ;
• une matrice de criticité probabilité × impact calculée automatiquement, avec filtre par niveau de criticité ;
• un plan de mitigation, un responsable et une échéance pour chaque risque, et la possibilité de le lier à une tâche du planning ;
• les risques critiques remontés dans le tableau de bord et dans la synthèse des rapports ;
• des données qui restent dans votre navigateur, sans compte ni serveur.

Le registre RAID fait partie de l'offre gratuite : après les 30 jours d'essai complet, il reste utilisable sur un projet sans payer.