Guide · Assistance à maîtrise d’ouvrage informatique (AMOA)
Un projet de logiciel de gestion ou d’outil métier commence rarement par le bon bout. Les démonstrations s’enchaînent, les fonctions annoncées ressemblent à celles dont l’entreprise a besoin, et personne n’a encore écrit noir sur blanc ce que les services attendent réellement. Cette page présente l’assistance à maîtrise d’ouvrage informatique : ce qu’elle recouvre, les moments où elle devient utile, les étapes d’une mission, les points de comparaison d’une offre et les erreurs qui reviennent souvent.
Sommaire
L’assistance à maîtrise d’ouvrage informatique, c’est quoi ?
L’assistance à maîtrise d’ouvrage, souvent appelée AMOA, désigne un appui apporté à l’entreprise qui commande un système d’information. Elle se place du côté de la maîtrise d’ouvrage, c’est-à-dire de l’entreprise qui exprime le besoin, décide et paie. La maîtrise d’œuvre, elle, est l’éditeur ou l’intégrateur qui réalise la solution. L’AMOA aide la première à tenir son rôle face à la seconde, sans prendre sa place.
Son terrain est le fonctionnel : ce que le logiciel doit permettre de faire, pour quels métiers, selon quelles règles de gestion. Elle ne développe pas, ne paramètre pas elle-même et ne pilote pas le projet dans son ensemble. La distinction tient en une phrase : le chef de projet pilote l’ensemble, l’AMOA porte les besoins des métiers et vérifie que la solution y répond.
Un rôle d’arbitre des besoins
Au départ, il faut traduire ce que les équipes font aujourd’hui en exigences écrites. L’AMOA organise des ateliers avec les métiers, recense les règles de gestion et rédige le cahier des charges fonctionnel. Ce document sert ensuite de référence pour comparer les offres et pour contrôler la livraison.
Un appui indépendant des fournisseurs
Pendant la consultation, l’assistant aide à construire le dossier, la grille de notation et les scénarios de démonstration. Il reste indépendant des solutions consultées, condition pour que le choix repose sur les besoins et non sur la présentation la plus convaincante. Lorsque le projet avance, il suit les échanges avec le maître d’œuvre et vérifie que ce qui est livré correspond à ce qui a été demandé.
Quand faut-il s’en occuper ?
Le besoin apparaît souvent après coup, lorsqu’un projet a déjà pris une mauvaise direction. Plusieurs situations reviennent :
- Des métiers qui peinent à dire ce qu’ils attendent : les demandes restent vagues, et chacun imagine un logiciel différent de celui de son voisin.
- Un éditeur qui écrit le cahier des charges : le document reflète alors les fonctions de sa solution plutôt que les besoins de l’entreprise.
- Des démonstrations impossibles à comparer : chaque candidat montre son meilleur scénario, et aucun ne reprend les situations réelles de l’entreprise.
- Un intégrateur qui livre ce qu’il a compris : les écarts ne se voient qu’à la mise en service, quand les équipes découvrent qu’une étape manque.
- Des règles de gestion connues d’une seule personne : son absence bloque la rédaction, puis le paramétrage.
- Une recette réduite à une validation : les cas courants n’ont pas été testés, et les anomalies surgissent après la mise en production.
- Des évolutions facturées pour des besoins connus dès le départ : ce qui n’a pas été exprimé à temps devient une demande supplémentaire.
- Une équipe informatique trop occupée pour porter la voix des métiers : les arbitrages fonctionnels se prennent sans les personnes qui vivent le processus au quotidien.
Comment se déroule un projet
Une mission d’AMOA suit trois temps. Sa durée dépend du périmètre fonctionnel et du nombre de métiers concernés : elle se fixe avec l’entreprise, sans délai garanti.
Avant : besoins et consultation
On commence par les ateliers avec les métiers. Les processus actuels sont décrits pas à pas, les règles de gestion sont écrites et leurs exceptions relevées. Vient ensuite le cahier des charges fonctionnel : besoins classés par priorité, données à reprendre, échanges avec les autres logiciels. C’est sur cette base que la consultation est lancée, avec une grille de notation établie à l’avance.
Pendant : démonstrations et suivi
Les candidats présentent leur solution sur des scénarios tirés de l’entreprise, et non sur leur démonstration standard. Les réponses sont comparées selon la grille. Après le choix et la signature, l’assistant suit le maître d’œuvre : il arbitre les questions fonctionnelles, valide les paramétrages et relève les écarts entre ce qui est livré et ce qui était demandé.
Après : recette fonctionnelle
La recette se prépare avant la livraison. Un cahier de recette couvre les cas courants et les cas limites, des jeux d’essai sont définis, et des utilisateurs clés mènent la campagne. Les anomalies et les réserves sont notées par écrit avant la mise en service. Une recette qui ne couvre que les fonctions les plus simples laisse à l’entreprise la charge des surprises.
Ce qui distingue une bonne offre
Deux propositions d’assistance peuvent annoncer les mêmes étapes sans se valoir. Quelques points méritent d’être comparés par écrit.
Le premier est l’indépendance. Il faut demander si l’assistant a un lien commercial avec l’un des éditeurs ou intégrateurs consultés, et ce lien doit être déclaré avant la signature. Le deuxième est la méthode : une offre sérieuse décrit comment les besoins seront recueillis, avec quelles personnes, et comment ils seront validés. Le troisième porte sur les livrables : cahier des charges, grille de notation, scénarios de démonstration, cahier de recette. Ils doivent être remis à l’entreprise, qui en reste propriétaire.
Le quatrième concerne la place réservée aux métiers. Une proposition qui ne prévoit que des échanges avec la direction informatique laisse de côté ceux qui utilisent le logiciel au quotidien. Enfin, demandez comment les réserves seront suivies après la recette, et qui tranche en cas de désaccord avec le maître d’œuvre. Une offre qui ne répond pas à ces questions reste floue sur ce qui sera réellement obtenu.
Les erreurs fréquentes
- Laisser l’éditeur rédiger le cahier des charges : le document décrit alors la solution proposée, et non le besoin. Parade : établir le cahier à partir des ateliers avec les métiers, avant toute consultation.
- Comparer des démonstrations commerciales : deux présentations standard ne disent rien de l’adéquation au quotidien. Parade : imposer des scénarios propres à l’entreprise, avec les mêmes données pour chaque candidat.
- Valider un paramétrage sans l’essayer : une validation sur papier ne révèle pas les cas particuliers. Parade : faire tester les parcours réels par des utilisateurs avant la mise en service.
- Bâcler la recette : une recette réduite à un contrôle rapide transforme les manques en demandes d’évolution facturées. Parade : écrire le cahier de recette et les jeux d’essai avant la livraison.
- Ne pas écrire les règles de gestion : connues d’une seule personne, leur absence bloque le projet au pire moment. Parade : les documenter pendant les ateliers et les faire valider par le responsable du processus concerné.
Les questions à poser avant de signer
L’assistant est-il indépendant des éditeurs et des intégrateurs consultés ? Demandez une déclaration écrite de tout lien commercial avec les candidats. Un lien non déclaré se découvre souvent au moment où le choix est contesté.
Comment les besoins des métiers sont-ils recueillis et validés ? Interrogez le nombre d’ateliers, les personnes concernées et la façon dont les règles de gestion seront confirmées par écrit.
Les démonstrations suivent-elles des scénarios propres à l’entreprise ? Vérifiez que chaque candidat présente les mêmes situations, à partir de données qui reflètent l’activité réelle.
Le cahier de recette et la campagne d’essais sont-ils compris dans la mission ? Une recette absente du contrat se découvre généralement au moment de la mise en service.
Pour démarrer, décrivez votre besoin dans le formulaire : un spécialiste de l’assistance à maîtrise d’ouvrage vous recontacte, gratuitement et sans engagement.