Il revient d’abord à la maîtrise d’ouvrage de définir les besoins du métier. Cette définition doit être adéquate aux besoins (pertinence), sobre, et conforme à la cohérence sémantique du SI (respect du référentiel).

Lorsque le SI existe, l’ensemble de ses fonctionnalités (processus, composants, interfaces homme-machine) constitue un « portefeuille » (le « portefeuille applicatif ») qui doit être géré comme tout actif de l’entreprise. Le portefeuille est un stock, alors que la réalisation des projets constitue un flux. Il ne convient pas de faire évoluer le portefeuille trop souvent [7], et tout investissement doit être précédé d’une évaluation de sa rentabilité mettant en regard le coût complet (y compris les dépenses de la MOA et le coût d’exploitation une fois le projet réalisé) ainsi que ses effets attendus. Comme pour un portefeuille financier, il faut évaluer les synergies entre divers projets : la solidité du SI vient souvent du fait que les applications s'appuient l'une sur l'autre, comme les deux parties d'une voûte. L'approche "système" du SI vise précisément à tirer parti de ces synergies.  

Si le projet est lancé, la MOA doit modéliser les processus (« spécifications générales ») dans des termes assez précis pour que l’informatique puisse se mettre au travail. L’informatique établit ensuite des spécifications détaillées que la MOA doit valider. (voir "La maîtrise d'ouvrage et ses utilisateurs")

La MOA dirige la réalisation du projet, avec l’assistance de la MOE. Si le projet dérape, si durant sa réalisation les exigences fonctionnelles évoluent, si le MOE ne remplit pas bien sa mission, c’est à la MOA qu’il revient de prendre les décisions nécessaires. La MOA est donc toujours responsable lorsqu’un projet échoue : soit elle aura été imprécise ou versatile dans l’expression des besoins, soit elle aura manqué de vigilance face à un MOE défaillant. Une MOA qui dit « l’informatique a échoué » reconnaît implicitement qu’elle n’a pas correctement assumé ses responsabilités, et en outre elle a tort de chercher à en faire porter la responsabilité à la MOE. Il faut dire, toutefois, que les entreprises donnent rarement à la MOA les moyens de ses responsabilités ; elles ont trop tendance à penser que "tout ça, c'est de l'informatique", et à confier la totalité des responsabilités à la MOE.

A la fin de la réalisation, la MOA vérifie que le produit rendra aux utilisateurs les services attendus (« recette fonctionnelle »). Elle doit ensuite assurer la formation des utilisateurs, le déploiement du produit, la conduite du changement (cf. ci-dessus), l’animation des bonnes pratiques, l’écoute des réclamations et suggestions éventuelles, etc.

(retour à "Repères essentiels pour la maîtrise d’ouvrage ")