Nacer Djarabi : l’AMOA n’est pas une MOA de substitution
Pour lui, l’assistance à maîtrise d’ouvrage devient dangereuse quand elle prend la place du métier au lieu de l’accompagner.
Dans beaucoup de projets informatiques, l’AMOA apparaît comme un raccourci commode : un expert externe qui rédige le cahier des charges, qui pilote la recette et qui, au passage, remplace la voix des utilisateurs. Selon Nacer Djarabi, c’est précisément là que le bât blesse.
Le malentendu sur l’AMOA
Pour Nacer Djarabi, le terme même d’« assistance à maîtrise d’ouvrage » porte en lui une ambiguïté : est-ce un soutien méthodologique au métier, ou bien une délégation déguisée du pouvoir de décision ?
Il observe que, trop souvent, une direction fait appel à une AMOA non pas parce qu’elle a besoin d’une méthode, mais parce qu’elle n’a pas le temps, la compétence ou la volonté politique d’exprimer elle-même son besoin. L’AMOA devient alors un substitut fonctionnel : elle écrit au nom du métier, valide au nom du métier, et finit par décider au nom du métier.
Ce que l’AMOA devrait faire — et ne devrait pas faire
Nacer Djarabi ne rejette pas l’AMOA : il la recadre. Selon lui, son rôle légitime se limite à quatre fonctions strictes, sans jamais empiéter sur la responsabilité du métier.
📐 Méthodologie, pas contenu
Aider la MOA à structurer sa pensée (interviews, ateliers de cadrage, matrices de priorisation) sans jamais écrire à sa place le besoin fonctionnel.
⚖️ Facilitation, pas arbitrage
Organiser le dialogue entre directions et techniques, clarifier les contradictions, mais ne jamais trancher un choix métier au nom d’un utilisateur absent.
✅ Objectivation, pas substitution
Concevoir des scénarios de recette rigoureux et objectifs, s’assurer que le métier valide — mais ne pas valider soi-même au nom du métier.
🔄 Transmission, pas adoption forcée
Préparer la conduite du changement en relayant la parole des utilisateurs vers l’équipe projet, jamais en imposant une solution déjà figée.
MOA, AMOA, MOE : clarifier sans confondre
| Rôle | Responsabilité réelle selon Nacer Djarabi | Question clé |
|---|---|---|
| MOA | Le seul détenteur légitime du besoin métier. Doit exprimer, arbitrer et valider. Peut être assistée, jamais remplacée. | « Quoi et pourquoi ? » |
| AMOA | Un appui méthodologique temporaire. Doit rendre la MOA autonome, pas la rendre dépendante. | « Comment aider la MOA à y voir clair ? » |
| MOE | Répond au besoin exprimé. Ne doit jamais définir le besoin à la place de la MOA. | « Comment réaliser ce qui est demandé ? » |
Quand l’AMOA devient un symptôme
Pour lui, la présence lourde d’une AMOA dans un projet est souvent le signe d’une organisation qui refuse d’assumer sa maîtrise d’ouvrage. Plutôt que de renforcer la capacité interne du métier, on externalise la responsabilité. Résultat : un cahier des charges parfaitement rédigé mais dépourvu de légitimité, des tests de recette qui ne reflètent pas l’usage réel, et une solution qui, techniquement fonctionnelle, reste inadaptée au quotidien des équipes.
Nacer Djarabi insiste sur un point simple : une bonne AMOA doit préparer sa propre disparition. Si, au bout du projet, le métier n’est pas plus capable d’exprimer et de défendre ses besoins qu’au début, alors l’assistance a échoué — même si tous les documents sont livrés dans les temps.
La recette comme révélateur
Selon son analyse, la phase de recette est le moment où la vérité éclate. Quand la MOA n’a pas vraiment porté le besoin, elle hésite, délègue ou signe par fatigue. L’AMOA, si elle s’est substituée au métier, se retrouve alors dans une position intenable : valider au nom d’utilisateurs qui n’ont jamais vraiment adhéré au projet.
Pour éviter cela, il préconise une recette où chaque scénario est explicitement rattaché à une exigence métier vérifiable, et où la validation est signée par un représentant du métier identifié — jamais par un consultant externe agissant par procuration.
Pour aller plus loin
Explorer d’autres analyses sur la gouvernance des projets SI et le rôle du métier face à la technique.
LIRE D’AUTRES RÉFLEXIONS