Le consultant AMOA (assistance à maîtrise d'ouvrage), pour assistance à maîtrise d’ouvrage, représente les intérêts du client sur un projet informatique. Il traduit le besoin métier en cahier des charges, compare les prestataires, pilote la réalisation et vérifie que ce qui est livré correspond à ce qui était dû.
Dit comme ça, le rôle paraît administratif. En pratique, c’est la personne qui vous évite de signer un devis que vous n’êtes pas en mesure de lire, et de réceptionner un logiciel dont vous ne pouvez pas prouver qu’il est incomplet.
Ce qu’il fait concrètement, étape par étape
Il fait parler ceux qui travaillent. Pas seulement ceux qui commandent. Un besoin recueilli uniquement auprès de la direction produit un cahier des charges qui décrit l’entreprise telle qu’elle se voit, pas telle qu’elle fonctionne. Les contournements que les opérationnels ont mis en place depuis des années sont la carte des vrais besoins, et personne ne les mentionne spontanément en comité.
Il écrit ce qui engage. Une expression de besoin lisible par un dirigeant et exploitable par un développeur, puis un cahier des charges assorti de critères de recette vérifiables. Cette dernière partie est celle que presque personne ne produit, et c’est celle qui décide de la fin du projet : sans critères écrits au départ, la réception devient une négociation sur le sens du mot « terminé ».
Il challenge les devis. C’est là que la valeur se concentre. Lire les exclusions avant les inclusions. Repérer l’intégration absente du chiffrage. Voir que la reprise de données est mentionnée en une ligne alors qu’elle représente un tiers du travail. Poser les questions techniques que le fournisseur n’attend pas.
Il pilote, puis il réceptionne. Comité de suivi, arbitrage des demandes nouvelles, qualification des écarts. Puis la recette : tester les cas de bord et les vraies données, pas seulement le parcours qui marche en démonstration. Et signer la réception quand c’est réellement livré, pas quand tout le monde est fatigué.
Le critère qui sépare un bon consultant d’un mauvais
Il tient en une question : est-ce que cette personne a déjà construit ?
La majorité des consultants AMOA viennent du conseil fonctionnel. Ils maîtrisent la méthode, animent correctement un atelier, tiennent un planning. C’est utile, et insuffisant sur un projet technique. Parce qu’au moment décisif, quand le prestataire explique qu’une contrainte technique interdit ce que vous demandez, un consultant sans expérience de construction ne peut que transmettre. Il devient un relais, pas un contrepoids.
Celui qui a écrit du code et piloté des architectures voit autre chose : un chiffrage gonflé, une intégration oubliée, et surtout la différence entre « ce n’est pas possible » et « je ne sais pas le faire ». Cette distinction, à elle seule, change l’équilibre d’une négociation.
Les quatre questions à poser avant de choisir
Quels livrables, précisément ? S’il ne peut pas les nommer au premier rendez-vous, il improvisera.
Avez-vous déjà lu un devis technique ligne par ligne ? Demandez un exemple de ce qu’il y a trouvé. La réponse est très parlante.
Que se passe-t-il si le prestataire livre hors périmètre ? La bonne réponse décrit un mécanisme, pas une intention : qualification de l’écart par rapport aux critères écrits, distinction entre défaut de livraison et demande nouvelle, puis options chiffrées.
Concourez-vous sur les projets que vous cadrez ? La question dérange, et c’est pour ça qu’il faut la poser.
Le conflit d’intérêt que personne n’aborde
Une société qui vous vend l’AMOA puis se propose de réaliser le projet est en situation de conflit. Ce n’est pas une question de moralité, c’est structurel : celui qui écrit les critères de choix ne peut pas se présenter au choix.
Autant l’assumer franchement de notre côté, puisque nous faisons aussi du développement. Notre règle : sur une mission d’AMOA, si le périmètre part en consultation, nous ne concourons pas. On ne peut pas écrire les règles du jeu et y participer. L’autre configuration est assumée à l’envers : si vous voulez qu’on construise, alors nous sommes votre maître d’œuvre, on le dit, et l’AMOA reste chez vous ou chez un tiers.
Ce qui n’arrive pas, c’est de cumuler les deux casquettes sur le même euro. Un prestataire qui n’a pas de position claire sur ce point vous en dit long.
AMOA, AMOE, MOA, MOE : la confusion utile à lever
Les sigles s’échangent constamment, y compris dans des appels d’offres publics.
La maîtrise d’ouvrage, la MOA (maîtrise d'ouvrage), c’est vous : celui qui a le besoin, le budget et le dernier mot. La maîtrise d’œuvre, la MOE, c’est celui qui construit. L’AMOA vous assiste côté besoin et contrôle. L’AMOE (assistance à maîtrise d'œuvre) assiste celui qui réalise, sur la conception technique et le pilotage du build.
En pratique, si vous cherchez quelqu’un pour vous défendre face à un fournisseur, c’est une AMOA, quel que soit le sigle écrit dans le document que vous avez reçu.
Quand ce n’est pas la bonne réponse
Par honnêteté : en dessous d’un certain enjeu, une AMOA coûte plus qu’elle ne protège. Elle devient rentable dès qu’il y a de l’argent significatif en jeu face à un prestataire, plusieurs services à concilier en interne, ou une reprise de données à instruire. Si votre cas ne le justifie pas, un simple cadrage court suffit à écrire le besoin et les critères de réception, et vous consultez ensuite seul.
Un consultant qui ne vous dit jamais que vous n’avez pas besoin de lui n’est pas un bon signe.
Pour aller plus loin
- Assistance à maîtrise d’ouvrage : le format de mission, du besoin à la réception
- Exemple de cahier des charges informatique : la trame que l’AMOA remplit avec vous
- Recette d’un logiciel : le plan de tests qui évite la mise en production ratée : la phase de contrôle, en détail
- Choisir son ERP en PME : pourquoi le cahier des charges ne doit pas venir de l’éditeur
- Expression de besoin ou cahier des charges : l’enchaînement que l’AMOA fait respecter
- AMOA ou AMOE : laquelle vous cherchez : deux rôles opposés que les appels d’offres mélangent
- AMOA dans un marché public : ce que le formalisme réglementaire ne remplace pas