Projet ERP : six risques à transformer en vérifications

Pour réduire le risque d’un projet ERP, transformez les inquiétudes en situations observables, puis en tests et en responsabilités. « La migration peut mal se passer » est trop vague. « Les pièces jointes pourraient manquer après la reprise » permet de demander un contrôle concret. Ce dossier propose une méthode de prévention, pas des statistiques d’échec ni des témoignages inventés.

Nommer le risque et sa conséquence

Décrivez l’événement possible, sa cause et son effet sur une opération précise. Une interface indisponible peut retarder les commandes ; un export incomplet peut rendre une sortie difficile. Séparez ce qui est déjà constaté de ce qui reste hypothétique. N’attribuez pas une probabilité chiffrée sans données. Vous pouvez classer les risques par gravité opérationnelle et capacité de détection, avec une échelle comprise par l’équipe. L’objectif est de préparer une action, pas de produire un score impressionnant qui donnerait une fausse précision à des appréciations subjectives.

Détecter les ambiguïtés de périmètre

Un besoin jugé évident par votre équipe peut être exclu de la proposition. Relisez les termes généraux et demandez une définition testable. Les reprises, les connecteurs, les états et les validations méritent une attention particulière. Associez chaque fonction indispensable à un composant, un livrable et un scénario. Si plusieurs prestataires interviennent, précisez la frontière de leurs responsabilités. Les zones grises doivent devenir des questions ouvertes dans le dossier de décision. Un accord oral non repris dans le périmètre reste difficile à suivre pendant l’exécution.

Contrôler les données et les accès

La qualité des données et la maîtrise des droits demandent des vérifications distinctes. Une donnée correcte peut être exposée à un profil trop large ; un accès bien limité peut porter sur un contenu mal repris. Définissez les contrôles de rapprochement et les règles d’habilitation avec leurs propriétaires. Testez les rejets, les remplacements et la suppression d’un accès. Les informations personnelles utilisées pendant le projet doivent être limitées et protégées. Faites examiner les questions de protection des données par votre DPO ou un conseil compétent lorsque les enjeux le nécessitent.

Prévenir la dépendance à une personne ou un acteur

Le projet devient fragile si une seule personne connaît le paramétrage, les accès ou les règles d’interface. Préparez une documentation exploitable et un remplacement. Côté prestataire, demandez comment l’équipe peut évoluer et comment les connaissances sont transmises. Cela ne signifie pas qu’un changement sera sans coût, mais vous devez savoir quels éléments seront remis. Conservez les comptes d’administration sous une gouvernance appropriée. Les accès de l’intégrateur doivent pouvoir être révoqués selon une procédure connue, sans rendre l’exploitation impossible pour votre organisation.

Suivre les réserves jusqu’à leur résolution

Un registre de risques n’est utile que s’il déclenche des actions. Pour chaque réserve, indiquez un responsable, une preuve attendue et un moment de décision. Réexaminez la situation lorsque le périmètre ou le calendrier change. Une mesure peut réduire un risque sans le supprimer ; documentez ce qui reste accepté. Avant le lancement, présentez les points bloquants et les contournements temporaires. Après la mise en service, continuez le suivi des réserves ouvertes. Évitez de les faire disparaître du compte rendu uniquement parce que le projet est déclaré terminé administrativement.

Exemple de travail

Scénario fictif et illustratif : un export de démonstration contient les clients et les factures, mais pas leurs pièces jointes. Le risque ne se résume pas à « dépendance fournisseur ». L’événement précis est l’impossibilité de récupérer les documents liés dans un format réutilisable. La mesure consiste à demander un export complet, à vérifier les liens et à chiffrer l’assistance. Le responsable des données valide le test. Si la fonction reste inconnue, la réserve figure dans la décision. Ce scénario n’est ni un retour d’expérience réel ni une critique d’un produit particulier.

Fiche de vérification

Élément	Question à documenter	Preuve ou responsable
Périmètre	Fonction indispensable omise	Démonstration et annexe
Données	Reprise incomplète	Rapprochement
Dépendance	Connaissance non transmise	Documentation testée
Sortie	Export inutilisable	Essai et budget

À faire dans votre équipe

Réunissez une personne métier et une personne technique pour choisir trois incidents qui empêcheraient réellement l’activité. Pour chacun, écrivez la première information qui permettrait de le détecter, la personne qui agirait et la preuve qu’une solution existe. Si l’une de ces cases reste vide, vous avez identifié un travail préparatoire. Ajoutez un cas de changement de prestataire et un cas d’indisponibilité d’un collaborateur clé. Ne multipliez pas les risques sans capacité de suivi : mieux vaut quelques actions vérifiées qu’un registre volumineux sans responsable. Relisez enfin les risques avant toute modification importante du périmètre, car une extension peut créer une dépendance nouvelle.

Questions fréquentes

Peut-on calculer un taux de risque global ?

Une note interne peut aider à discuter, mais elle n’est pas une probabilité ni une certification. Les critères et leurs limites doivent être explicités.

Les exemples sont-ils des échecs réels ?

Non. Les scénarios de ce site sont illustratifs lorsqu’aucune source de cas réel n’est citée. Ils servent à préparer des vérifications, sans attribuer de comportement à un fournisseur.

Qui accepte un risque résiduel ?

Le responsable habilité doit décider avec les personnes concernées, à partir d’une conséquence comprise et des mesures disponibles. Cette décision doit être traçable.

Pour poursuivre

Sources et portée

CNIL — rôles des acteurs du cloud — référence officielle consultée le 30 octobre 2026.

Les démarches, tableaux et scénarios sont des propositions de méthode propres à ce guide. La référence officielle permet de vérifier les conditions ou notions mentionnées ; elle ne valide pas les hypothèses chiffrées illustratives et ne constitue pas un classement de produits.