Pourquoi le cadrage AMOA conditionne tout le projet
Un cadrage AMOA SI sert à transformer une intention en décisions exploitables : périmètre, processus, données, interfaces, rôles, risques, critères de choix, recette et conditions de bascule. Il ne s’agit pas seulement de rédiger un cahier des charges, mais de réduire les ambiguïtés avant qu’elles deviennent des coûts de projet.
Les erreurs ci-dessous apparaissent souvent avant même le choix d’une solution ou d’un intégrateur. Chaque erreur doit être traitée par un livrable, une décision ou un contrôle vérifiable.
Erreur 1 — Décrire le processus théorique au lieu du réel
Le problème : les ateliers décrivent le fonctionnement attendu, pas les exceptions réellement gérées par les équipes. La conséquence : le paramétrage couvre le cas nominal et laisse de côté les situations qui consomment le plus de temps.
À produire : une cartographie du processus réel, avec variantes, volumes, irritants, règles d’exception et points de contrôle.
Erreur 2 — Confondre besoin métier et solution
Le problème : les demandes arrivent sous forme de fonctionnalités ou de noms d’outils. La conséquence : le projet arbitre trop tôt une réponse technique sans qualifier le besoin, le risque et la valeur d’usage.
À décider : le résultat attendu, les contraintes, les données nécessaires et les critères qui permettront de comparer plusieurs réponses possibles.
Erreur 3 — Mal identifier les acteurs
Le problème : les utilisateurs clés, valideurs, exploitants, administrateurs, contrôleurs et équipes support ne sont pas tous représentés. La conséquence : certaines exigences apparaissent en recette ou après démarrage.
À contrôler : une matrice des rôles métier, DSI, intégrateur, direction, support et propriétaires de données.
Erreur 4 — Sous-estimer les interfaces
Le problème : les flux avec ERP, CRM, GMAO, finance, RH, référentiels ou outils décisionnels sont décrits trop tard. La conséquence : le planning dérive, les responsabilités se brouillent et les tests d’intégration deviennent incomplets.
À produire : une cartographie des flux avec données échangées, sens, fréquence, système maître, règles d’erreur et responsabilités.
Erreur 5 — Reporter la qualité des données
Le problème : la reprise est traitée comme une opération technique de fin de projet. La conséquence : doublons, champs vides, historiques inutilisables ou référentiels incohérents bloquent la recette.
À décider : ce qui est repris, nettoyé, archivé, reconstruit ou abandonné, avec un responsable métier pour valider les données critiques.
Erreur 6 — Laisser les exigences sans arbitrage
Le problème : toutes les demandes restent au même niveau de priorité. La conséquence : le périmètre grossit, les délais deviennent irréalistes et les choix sont repoussés à l’intégrateur.
À contrôler : une liste d’exigences classées, avec statut obligatoire, utile, différable ou hors périmètre, et une trace des décisions.
Erreur 7 — Oublier les critères de recette
Le problème : la recette vérifie la présence des fonctions plutôt que les situations métier. La conséquence : un écran validé ne prouve pas que le processus fonctionne de bout en bout.
À produire : des scénarios de recette couvrant cas nominal, exception, reprise, interface, droit d’accès, reporting et clôture.
Erreur 8 — Préparer trop tard la bascule
Le problème : formation, support, habilitations, données finales et procédures de secours sont traités après le paramétrage. La conséquence : le démarrage concentre trop de risques opérationnels.
À décider : stratégie de bascule, fenêtre de migration, plan de formation, support de démarrage, critères de go/no go et plan de retour si nécessaire.
Erreur 9 — Mélanger les rôles métier, DSI et intégrateur
Le problème : les responsabilités de décision, conception, paramétrage, validation et arbitrage ne sont pas séparées. La conséquence : chacun pense que l’autre porte la décision.
À contrôler : un RACI de projet, complété par un circuit d’arbitrage court pour les sujets bloquants.
Erreur 10 — Ne pas décider le modèle cible
Le problème : le projet démarre sans choix clair sur l’organisation future, les processus standardisés, les règles locales et le niveau d’autonomie attendu. La conséquence : le système reproduit les ambiguïtés existantes.
À décider : modèle cible, écarts acceptés, règles communes, responsabilités de maintenance et indicateurs de suivi après mise en production.
Pour cadrer le périmètre, les rôles, les interfaces, la reprise de données et les critères de recette, voir notre accompagnement AMOA SI. Lorsqu’une application métier est au centre du projet, le cadrage doit aussi intégrer ses contraintes propres, par exemple un projet ERP ou une GMAO.
Vous devez cadrer, reprendre ou arbitrer un projet SI avant consultation ou déploiement ? Échanger sur votre cadrage AMOA SI.