Conseil en stratégie, design et gouvernance des infrastructures

dictionnaire MOA Projet

Appel d’offres, appel à candidatures

En cas de recours à des fournisseurs et prestataires externes, le maître d’ouvrage d’un projet informatique peut émettre un appel d’offres, leur demandant des offres de produits et de services.

Que doit contenir un appel d’offres ? Un appel d’offres contient le cahier des charges des produits et des services demandés et les conditions de déroulement de la consultation (contenu attendu de la réponse, délai de fourniture de la réponse, modalités de fourniture d’informations complémentaires…). Les consultations sont normalement lancées après l’étude préalable du projet, en fournissant aux candidats la définition de la solution attendue obtenue dans cette étude. Elles peuvent porter sur des progiciels, des matériels et logiciels de base, des réseaux, des prestations d’ingénierie informatique, de conduite du changement, d’infogérance. Conseil Projet Organisation SI

Quand faut-il faire un appel d’offres ? Quand on y est obligé pour des raisons réglementaires. Pour obtenir la meilleure offre technique et financière par mise en concurrence de plusieurs fournisseurs et prestataires potentiels capables de fournir le produit attendu ou de réaliser la prestation attendue. L’intérêt d’un appel d’offres est de disposer de plusieurs réponses à une consultation, ce qui d’une part apporte des idées, et d’autre part permet de choisir. Mais il ne faut pas négliger le fait que cette procédure demande plus de travail pour la maîtrise d’ouvrage : nécessité d’établir un cahier des charges écrit (ce qui est a priori une bonne chose, pour des opérations complexes), de fournir des informations complémentaires à plusieurs sociétés et de dépouiller plusieurs offres.

Une démarche en deux temps Pour sélectionner le prestataire le mieux placé pour mener à bien le projet, il peut être intéressant de s’inspirer de techniques d’appels d’offres codifiés dans les appels d’offres publics ou européens et d’utiliser une démarche en deux temps. On peut procéder dans une première étape à une consultation préliminaire ou appel à candidatures (Request For Information, ou RFI en anglais) : émission d’un cahier des charges simplifié demandant une présentation de l’aptitude des candidats à fournir les produits et les services demandés. L’appel à candidature est émis vers un large éventail de fournisseurs et de prestataires : son objectif est d’établir une liste restreinte des candidats à consulter lors de l’émission de l’appel d’offres. Il est possible aussi, pour un appel d’offres de caractère technique, d’émettre d’abord un « appel à technologies », qui n’est pas encore l’appel d’offres pour les produits matériels et logiciels, mais qui demande des propositions d’architectures, de solutions. Une autre possibilité est de faire une pré-sélection, avec le type de démarche qui vient d’être présenté, puis de confier, par exemple à deux sociétés retenues, la réalisation d’une étude technique rémunérée sur la base de laquelle sera choisi le prestataire final.

Remarques Pour les services, il peut être intéressant de segmenter les travaux de façon à faire intervenir plusieurs prestataires candidats plutôt que de tout confier à un seul prestataire. Il est parfois plus profitable pour le client d’utiliser les compétences de plusieurs prestataires et de créer entre eux une saine émulation. La contrepartie est que l’intégration globale des résultats obtenus est à faire, par le client ou par un maître d’œuvre externe. La réponse à un appel d’offres demande un travail important pour les fournisseurs et les prestataires consultés. Pour obtenir des réponses sérieuses, il est souhaitable de limiter le nombre des sociétés consultées : si ces sociétés sont trop nombreuses, elles le sauront, et elles seront moins motivées pour faire une offre sérieuse. Il faut aussi un nombre suffisant de bonnes réponses. Pour cela nous conseillons de consulter entre trois et cinq fournisseurs et prestataires, pour être certain d’obtenir entre une et trois bonnes réponses.

Assurance qualité

La complexité des systèmes informatiques est telle que le zéro défaut est pratiquement impossible à obtenir dans les projets pour les travaux d’ingénierie informatique. Il est possible toutefois de s’en approcher et d’arriver à un taux de dysfonctionnements acceptable par la maîtrise d’ouvrage.

Pour cela, une démarche Qualité formelle doit être mise en place par la maîtrise d’œuvre. Elle doit privilégier les actions préventives (Assurance Qualité) plutôt que correctives (Contrôle Qualité). En effet, d’une part il est beaucoup moins coûteux de rectifier une erreur en amont qu’en aval. D’autre part les contrôles de conformité réalisés à la fin du projet ne peuvent pas être exhaustifs : il est nécessaire de les compléter par des contrôles pendant le déroulement du projet.

Certains aspects de la démarche concernent la maîtrise d’ouvrage : le référentiel de définition des spécifications, par exemple, doit être validé par la maîtrise d’ouvrage ; la mise en œuvre de certaines dispositions par la maîtrise d’œuvre doit pouvoir être contrôlée par la maîtrise d’ouvrage, qui doit de ce fait les connaître, savoir où sont les traces correspondantes.

Pour la mise en place d’un nouveau système informatique, la maîtrise d’œuvre de l’ingénierie informatique formalise, avec la maîtrise d’ouvrage, cette démarche sous forme de Plan Qualité du projet. Ce document définit l’ensemble des actions qu’elle prévoit pour obtenir le niveau de qualité requis pour le système à construire, ainsi que les procédures d’interface entre la maîtrise d’ouvrage et la maîtrise d’œuvre. Ce Plan Qualité est validé par la maîtrise d’ouvrage pour tout ce qui concerne ses relations avec la maîtrise d’œuvre. Pour le reste, la maîtrise d’ouvrage est simplement informée.

Dans le cas de l’intervention d’un prestataire externe, le cadre d’Assurance Qualité du contrat doit être cohérent avec celui de l’entreprise. En matière de qualité, la principale problématique des projets informatiques concerne la conformité des logiciels aux spécifications. Il arrive malheureusement souvent qu’une équipe de projet en retard ne réalise pas des contrôles et des tests suffisants des logiciels, et compte sur le maître d’ouvrage pour finir de tester le système. Par ailleurs, les tests de recette effectués par la maîtrise d’ouvrage ne sont jamais exhaustifs, et de toute façon viennent trop tard. Il est donc très important que le prestataire définisse à l’avance les différents niveaux de test et de contrôle qu’il prévoit de réaliser, et que le client puisse vérifier pendant le déroulement du projet que le prestataire a fait ce qu’il a écrit qu’il ferait.

Audit

Plusieurs types d’audit de projet informatique peuvent être réalisés : audit d’ensemble du projet, interne ou externe, à la demande de la maîtrise d’ouvrage, portant sur les conditions de réussite du projet :
Audit contractuel, déclenché par le client, selon des dispositions et dans des conditions prévues à l’avance dans le contrat (délais de préavis, modalités d’exécution de l’audit, participation du prestataire, communication des résultats…), pour savoir où en est le projet sur le plan technique, du planning, si les contrôles prévus par le prestataire sont effectués, et si le prestataire est toujours en mesure de respecter ses engagements par rapport au client ; audit qualité prévu au Plan Qualité du projet ou du contrat, déclenché par le client ou par le prestataire (les règles de participation éventuelle du client et de communication des résultats doivent avoir été définies) ;
Audit technique, d’organisation, financier, de procédures… La direction qualité ou la cellule audit du client peuvent être partie intégrante de l’organisation du projet et réaliser des audits réguliers de la qualité de la prestation et des produits. C’est de loin la meilleure solution pour prévenir les dysfonctionnements et les non-qualité.

Les audits peuvent être soit réguliers, périodiques…, soit effectués à la demande, si la direction du projet (maîtrise d’ouvrage ou maîtrise d’œuvre) se pose une question ponctuelle. Étant donné la complexité des projets informatiques, les audits, même coûteux, sont très souvent utiles et donc rentabilisés.

Les audits peuvent être réalisés par des équipes internes de l’entreprise, ou par des tiers. Il faut trouver un auditeur compétent, de bonne foi, et, dans le cas des audits contractuels, non-concurrent du prestataire.

La possibilité pour un client de faire un audit contractuel ne l’autorise pas à accéder à des informations confidentielles du prestataire (par exemple les dossiers personnels des collaborateurs, ou des informations financières).

Benchmarking

En français, « banc d’essai ». Pratique utile dans le cadre d’un projet pour évaluer la productivité d’un AGL, les performances d’un logiciel ou d’un matériel ou pour faire des tests comparatifs préalables au choix d’un progiciel. Cependant, sa mise en œuvre demande souvent un tel investissement qu’elle reste au stade des intentions. C’est dommage car cela pourrait éviter par la suite de graves pertes de temps dues à un choix malheureux.

Si on propose au maître d’ouvrage une architecture technique complètement nouvelle, nous lui conseillons d’imposer que des tests techniques préalables significatifs soient réalisés avant de choisir définitivement la solution technique, et de passer commande du système.

Attention ! ne pas confondre ce benchmarking avec le benchmarking des services, qui vise plutôt à comparer des niveaux de service, des prix, des méthodes…

Cahier des charges

Un cahier des charges est établi pour la réalisation d’un projet informatique complet, ou, plus souvent, plusieurs cahiers des charges sont établis pour les différentes parties du projet. Le cahier des charges est émis par le maître d’ouvrage. C’est un document qui contient la définition des besoins auxquels le fournisseur ou le prestataire doit répondre dans le cadre du projet, et des contraintes que le prestataire doit respecter.

Le cahier des charges d’un projet informatique contient les besoins des utilisateurs, des exploitants et des mainteneurs. Les besoins explicités s’expriment sous forme de spécifications attendues (du système ou des services attendus).

L’expression des besoins doit tenir compte des besoins actuels, et aussi de leurs évolutions prévisibles à moyen terme. Un cahier des charges peut être établi pour les éditeurs de progiciels, les fournisseurs d’infrastructure technique, et pour chaque maître d’œuvre. On pourra trouver des cahiers des charges de progiciels, d’infrastructure technique, d’ingénierie informatique, de conduite du changement, de mise en fonctionnement du système informatique (ce dernier cahier des charges correspondra d’ailleurs souvent à la partie « prise en charge » du cahier des charges d’infogérance ou de TMA).

Le cahier des charges portant sur l’ensemble d’un projet doit contenir les informations suivantes :
Présentation générale de l’entreprise : activité, effectifs, implantation géographique ;
Présentation du système d’information existant de l’entreprise, en détaillant les parties qu’il est prévu de remplacer, de transformer, et les parties avec lesquelles interopère le système cible du projet ;
Objectifs du projet ; contraintes à prendre en compte ;
Organisation générale du projet ; démarche globale envisagée ; organisation prévue pour le fonctionnement et les évolutions du système ;
Expression des besoins relative au système d’information cible : nouveaux processus métier envisagés, fonctions attendues du nouveau système informatique, volumétrie, niveaux de service, caractéristiques techniques, qualité et sécurité ;
Expression des besoins relative aux services attendus : lotissement des prestations, description, livrables… ;
Management du contrat, clauses juridiques.

Quelles sont les caractéristiques d’un « bon » cahier des charges ?

Il doit être clair, ce qui contribue à la pertinence des réponses fournies à la maîtrise d’ouvrage (le candidat a compris la demande). Il doit être précis et complet, ce qui évite à la maîtrise d’ouvrage de passer trop de temps à répondre aux questions des sociétés consultées. Il doit être rédigé en termes de besoins, et non de solutions, de façon à permettre aux sociétés consultées de faire preuve d’initiative et d’originalité dans la conception des solutions qu’elles proposent.

Cycle de vie

Ensemble et enchaînement des travaux à réaliser en vue de concevoir, réaliser, mettre en place, faire fonctionner et faire évoluer un système d’information.

Le cycle de vie d’un système d’information dépend de ses caractéristiques, des besoins et de l’organisation de l’entreprise qui l’utilise. D’une façon très macroscopique, du point de vue de la maîtrise d’ouvrage, il comporte tout ou partie des étapes suivantes :
Étude préalable à la mise en place d’un nouveau système d’information
Lancement du projet informatique
Projet d’ingénierie informatique
Expression des besoins
Conception générale, puis détaillée du système informatique
Validation des spécifications du système
Réalisation, puis intégration des composants
Tests, contrôles
Recette des travaux (Validation d’Aptitude au Bon Fonctionnement (VABF))
Projet de conduite du changement
Mise en fonctionnement du nouveau SI
Recette (VABF)
Bascule
Démarrage du nouveau SI
Fonctionnement : exploitation informatique, maintenance des matériels et des logiciels, support utilisateurs
Vérification de Service Régulier (VSR)
Évolutions du système d’information : réalisation des évolutions du système informatique, des processus métier associés
Arrêt du fonctionnement du système d’information.

Sur le plan technique, les cycles de vie sont beaucoup plus détaillés que ce qui vient d’être présenté. Ils précisent le découpage en étapes, en tâches élémentaires, les rôles détaillés de chaque acteur technique. La définition du cycle de vie des systèmes d’information est d’abord une question de méthode, qui concerne la maîtrise d’œuvre. Par certains aspects, elle concerne aussi la maîtrise d’ouvrage. On constate tout d’abord qu’on dépense beaucoup plus d’argent dans les phases « fonctionnement » et « évolutions » du cycle de vie que dans la phase « projet ». Cela veut dire qu’il faut, dans la phase « projet », penser aux phases suivantes, et veiller à l’exploitabilité, l’évolutivité, la maintenabilité du futur système informatique. Cela signifie notamment de faire en sorte que les logiciels applicatifs, qui appartiennent à la maîtrise d’ouvrage, doivent respecter des normes techniques, de documentation…

Par ailleurs, le cycle de vie traditionnel des systèmes d’information correspond à un enchaînement de type : expression des besoins – conception générale – conception détaillée – réalisation – test – recette. Ce type d’enchaînement, dit cycle en V, présente un défaut connu. Si on l’applique à l’ensemble du système, on constate un effet dit « tunnel » : la livraison du système attendu se fait en une seule fois, et longtemps après que les spécifications aient été validées. Pour cette raison, quand c’est possible (et c’est souvent le cas pour les projets à base de progiciel), il vaut mieux appliquer le cycle en V à des sous-ensembles du système, ou choisir des cycles de développement itératifs, ce qui permet de simplifier la démarche, en réduisant la durée du cycle. La difficulté est alors de gérer la cohérence des sous-ensembles, ou de gérer les versions.

Ingénierie informatique

Les projets informatiques comportent un volet « ingénierie informatique ». L’ingénierie informatique est la prise en charge de la conception, de la réalisation et de la mise en place d’un nouveau système informatique, ou de la transformation d’un système informatique existant. Elle correspond à la fourniture d’un système informatique complet, matériels, logiciels et réseaux, répondant à un cahier des charges exprimant les besoins des utilisateurs et le contexte technique de la fourniture.

Les livrables de la prestation d’ingénierie informatique sont : un système informatique opérationnel, matériel et logiciel, fonctionnant conformément aux spécifications convenues (fonctionnalités, performances…) ; des documentations pour les utilisateurs, les équipes d’exploitation, de maintenance ; des actions de formation des équipes techniques d’exploitation et de maintenance applicative, de transfert de compétences.

Les travaux à réaliser correspondent à tout ou partie de la liste suivante : conception générale et détaillée, fonctionnelle et technique du système informatique ; définition de l’architecture du système ; installation de matériels, de logiciels, de réseaux ; paramétrage, vérification de leur bon fonctionnement ; programmation de logiciels spécifiques ; tests unitaires ; transformation, ré-ingénierie de logiciels existants (amélioration de leur qualité, changement de système d’exploitation…) ; paramétrage de progiciels, développement spécifiques ; réalisation des documentations prévues (utilisateurs, de maintenance, d’exploitation) ; formation des équipes techniques ; transfert de compétences ; migration des données disponibles sur les fichiers existants ; intégration et tests de l’ensemble du système (matériels, logiciels, réseaux, données) ; présentation en recette, correction des défauts ; garantie.

Le responsable de l’ingénierie informatique peut être un prestataire externe ou l’entreprise (la DSI), qui peut sous-traiter une partie des travaux auprès de prestataires externes.

Dans les projets informatiques, le volet ingénierie constitue une grande partie du budget du projet, et l’essentiel du risque technique. L’ingénierie informatique est une discipline encore insuffisamment mature, et qui est handicapée par la rapidité de l’évolution technologique. Cela signifie que la maîtrise d’ouvrage doit être d’une part particulièrement vigilante, et d’autre part doit être capable, en face de la maîtrise d’œuvre, de faire preuve à la fois de rigueur, de souplesse et de réactivité.

Logiciels

Le système informatique cible d’un projet informatique comporte des logiciels. Ils se répartissent en trois catégories : les logiciels applicatifs, qui proposent des fonctions aux utilisateurs finals : gestion, calcul scientifique, contrôle de processus, bureautique… ; les logiciels de base : systèmes d’exploitation, Systèmes de Gestion de Bases de Données… ; les logiciels « outils » pour informaticiens : outils et automates d’exploitation paramétrables, ateliers de génie logiciel…

Les logiciels applicatifs peuvent être standard (progiciels de gestion d’entreprise, logiciels bureautiques) ou spécifiques. Les logiciels de base et les logiciels outils sont toujours des logiciels standard. Un logiciel est composé concrètement de code source (langage pouvant être traité par un outil de type compilateur ou interpréteur), d’une documentation (d’utilisation, d’exploitation et de maintenance) et de dossiers et fichiers de test. Les différents types de logiciels sont liés entre eux, et avec les matériels. Par exemple : un système d’exploitation est associé à un matériel, et est vendu avec le matériel ; un SGBD fonctionne avec certains systèmes d’exploitation ; un logiciel applicatif fonctionne avec certains systèmes d’exploitation et certains SGBD.

La maîtrise d’ouvrage a un rôle majeur à jouer pour les logiciels applicatifs : elle exprime ses besoins, valide les spécifications, choisit les progiciels, les paramètre, recette les applications. Les caractéristiques techniques des logiciels applicatifs spécifiques, telles que la qualité de la programmation, de la documentation… intéressent aussi la maîtrise d’ouvrage, dans la mesure où elle est propriétaire des éléments spécifiques, et où ces caractéristiques sont des gages d’exploitabilité, de maintenabilité, d’évolutivité des applications. Les autres logiciels sont financés d’une manière ou d’une autre par la maîtrise d’ouvrage, mais ils sont choisis et proposés par la maîtrise d’œuvre. Il appartient à la maîtrise d’ouvrage de vérifier (ou de faire vérifier) que c’est le meilleur choix, en termes de fiabilité, de standardisation, de pérennité.

Maître d’oeuvre, maître d’ouvrage

Ouvrage et œuvre

Au sens retenu dans les concepts de maîtrise d’ouvrage et de maîtrise d’œuvre, l’ouvrage est un objet produit par le travail d’un professionnel, tandis que l’œuvre est le travail fourni par le professionnel pour réaliser l’objet. Dans le cas des projets informatiques, ces définitions s’appliquent parfaitement à l’ingénierie informatique, où le résultat du travail du prestataire est le système informatique, qui est un objet visible, tangible. Elles peuvent s’appliquer par analogie aux autres travaux (formation, mise en fonctionnement…).

Maître d’œuvre, maîtrise d’œuvre

Un maître d’œuvre est un professionnel responsable de la production d’un objet, ou de la fourniture d’un service. Le maître d’œuvre peut être externe ou interne à l’entreprise. La maîtrise d’œuvre est l’ensemble des fonctions exercées par le maître d’œuvre : on exerce la maîtrise d’œuvre d’un projet, d’une prestation. Par extension, on désignera également par « maîtrise d’œuvre » l’ensemble des personnes qui exercent la maîtrise d’œuvre.

Maître d’ouvrage, maîtrise d’ouvrage

Le maître d’ouvrage est le propriétaire de l’objet produit, ou le bénéficiaire des services fournis. Le rôle du maître d’ouvrage par rapport au maître d’œuvre est de choisir le maître d’œuvre, d’exprimer ses besoins, de valider les spécifications du produit à réaliser ou de la prestation à fournir, éventuellement de participer aux travaux, de suivre les travaux, de recetter la livraison, de payer le prix convenu. La maîtrise d’ouvrage est l’ensemble des fonctions exercées par le maître d’ouvrage : on exerce la maîtrise d’ouvrage d’un projet. Par extension, on désignera également par « maîtrise d’ouvrage » l’ensemble des personnes de l’entreprise qui exercent la maîtrise d’ouvrage.

Maîtrise d’ouvrage et maîtrises d’œuvre des projets informatiques

La maîtrise d’ouvrage des projets informatiques est définie dans l’avant-propos de ce livre. Un projet informatique peut avoir plusieurs maîtres d’œuvre, chargés respectivement de l’ingénierie informatique, de la conduite du changement, de la mise en fonctionnement du nouveau système. Dans les grands projets, des maîtres d’œuvre peuvent également être désignés par délégation, par exemple pour une partie des travaux d’ingénierie informatique. Sur le plan juridique, le maître d’ouvrage d’un projet informatique est l’entreprise elle-même : c’est l’entreprise qui passe les commandes, qui finance le projet, qui est propriétaire de tout ou partie du système d’information réalisé, et dont le personnel utilise le nouveau système. La direction générale de l’entreprise désigne un maître d’ouvrage pour chaque projet informatique. Dans le cas où le nouveau système est destiné à des utilisateurs internes, c’est souvent le responsable hiérarchique de ces utilisateurs, ou un de ses proches collaborateurs. Pour les projets concernant l’ensemble de l’entreprise, cela peut être le directeur général lui-même. Un projet peut être réalisé pour plusieurs entreprises, ou plusieurs organismes. Ils doivent s’organiser entre eux, par exemple en désignant un mandataire commun, qui les représente auprès des maîtres d’œuvre. Le maître d’ouvrage du projet informatique n’a pas toujours une délégation complète pour prendre toutes les décisions se rapportant au projet. Il intervient dans le cadre de l’organisation générale de l’entreprise. Pour certaines décisions, il peut devoir demander une approbation à la direction générale de l’entreprise, à son conseil d’administration, à des directions fonctionnelles, des organismes de contrôle externes.

Relations entre maîtrise d’ouvrage et maîtrise d’œuvre

On entend régulièrement des réflexions sur le caractère désuet, non-opérationnel de la distinction entre maîtrise d’ouvrage et maîtrise d’œuvre. Il est clair que, pour les projets informatiques, la relation entre maîtrise d’ouvrage et maîtrise d’œuvre n’est pas aussi simple que par exemple dans le Bâtiment : la spécification et la recette des systèmes sont plus lourdes et plus complexes, les techniques sont moins stabilisées, et dans beaucoup de phases du projet la maîtrise d’ouvrage est amenée à collaborer avec la maîtrise d’œuvre. Ce qui est clair, c’est que dans les relations entre entreprises, il y a une entreprise cliente, qui est propriétaire du futur système d’information et qui le paie, et une ou plusieurs entreprises prestataires. Les contrats de travaux signés entre client et prestataires font apparaître des relations de type maîtrise d’ouvrage/maîtrise d’œuvre : expression des besoins, spécification du système à réaliser ou des services à fournir, recette ou contrôle des livraisons. Ces relations sont à adapter à la nature des systèmes informatiques, et des travaux : en particulier, quand l’entreprise cliente participe activement aux travaux de réalisation, comme pour le paramétrage d’un progiciel, la responsabilité du prestataire n’est pas de même nature que quand la réalisation est faite complètement par le prestataire.

Dans l’organisation interne de l’entreprise, les directions utilisatrices et la direction des systèmes d’information ont également des relations de type maîtrise d’ouvrage/maîtrise d’œuvre, avec le même type de réserves.

Recette du SI

Vérification, par la maîtrise d’ouvrage, de la conformité du système informatique livré aux spécifications convenues. En cas de conformité, le maître d’ouvrage prononce la recette, éventuellement avec des réserves. En cas de non-conformité, il refuse la recette. Les spécifications ne doivent contenir que des aspects recettables, c’est-à-dire des caractéristiques qu’il est possible de contrôler objectivement par des tests.La recette se déroule fréquemment en deux temps : recette provisoire, avant la mise en exploitation, prononcée sur la base d’une Vérification d’Aptitude au Bon Fonctionnement (VABF) ; recette définitive, prononcée après une certaine durée de fonctionnement du système, éventuellement sur la base d’une Vérification de Service Régulier (VSR). La recette provisoire comporte trois volets : recette utilisateurs (conformité aux spécifications fonctionnelles), recettes d’exploitabilité et de maintenabilité. Théoriquement, le maître d’ouvrage ne devrait pas avoir besoin de recetter le système informatique : c’est au maître d’œuvre de l’ingénierie informatique de réaliser les tests nécessaires de conformité avant la livraison. Dans la pratique, la recette par le maître d’ouvrage est nécessaire parce qu’il peut toujours subsister des ambiguïtés, des imprécisions dans les spécifications, et parce que les tests d’un système informatique sont tellement difficiles qu’il est nécessaire de compléter les tests du fabricant du système par des tests effectués par le client, avec une vision « métier ». Il n’empêche que le maître d’œuvre de l’ingénierie informatique est tenu de réaliser tous les tests nécessaires avant la présentation en livraison, et qu’il ne doit pas prendre prétexte de la réalisation de tests par la maîtrise d’ouvrage pour alléger son travail et atténuer sa responsabilité.

La recette est une opération lourde pour la maîtrise d’ouvrage : les tests doivent être suffisamment nombreux, et la constitution des bases de données de départ peut être laborieuse. Pour recetter un système informatique complexe, si on ne l’a jamais fait, il est souhaitable de recourir à l’assistance de personnes qui en ont l’expérience.

Risques

Les principaux risques liés à un projet informatique sont : l’abandon du projet en cours de déroulement ; la non-atteinte des objectifs du projet ; la non conformité du système livré aux spécifications convenues ; le dépassement des délais ; le dépassement des budgets ; le risque social. Les principaux facteurs de risque des projets informatiques (taille, nouveauté, technologies mises en œuvre…) sont présentés au début de ce livre. Leur analyse conduit à définir des actions de maîtrise des risques adaptées au contexte du projet.

Spécifications d’un SI

Les spécifications d’un système informatique, ou d’un service associé, sont les caractéristiques attendues du système ou du service. Elles sont établies par la maîtrise d’œuvre de l’ingénierie informatique, ou du fonctionnement du système, à partir d’une expression des besoins de la maîtrise d’ouvrage. Elles sont validées par la maîtrise d’ouvrage. Elles peuvent être générales ou détaillées, fonctionnelles ou techniques. Elles peuvent porter sur la totalité du système, ou sur une partie.

Les spécifications sont un document contractuel. Le maître d’œuvre qui propose des spécifications garantit la fourniture du système ou du service spécifié et, dans des limites à définir en fonction du niveau de détail des spécifications, garantit des délais et des prix. Le maître d’ouvrage valide les spécifications du système et des services fournis dans le cadre du projet. Les spécifications d’un système informatique portent sur : les fonctionnalités du système ; son architecture ; sa capacité maximale en termes de volumes (nombre d’unités d’œuvre fonctionnelles (contrats à gérer, clients, factures…), nombre d’utilisateurs…) ; son implantation géographique, ses conditions d’accès par les utilisateurs ; ses conditions d’exploitation et de maintenance ; le niveau de qualité du système (performances, fiabilité, maintenabilité, exploitabilité…) ; le niveau de sécurité du système (durée maximale d’interruption du fonctionnement, protection contre les accès non autorisés…).

Pour les services associés, dans le cadre des projets informatiques (formation des utilisateurs, déploiement du système…) ou du fonctionnement du système (exploitation, maintenance…), les spécifications portent sur : la nature du service (livrables, réponse à des questions…), le périmètre du service ; l’amplitude horaire de fourniture du service ; le nombre et l’implantation des utilisateurs ; les conditions de fourniture du service, les niveaux de service : délais à respecter, conditions de demande…

Les spécifications sont écrites, dans des dossiers de spécification. La définition et la validation des spécifications, générales puis détaillées, du système informatique et des services associés, sont des étapes fondamentales, voire fondatrices, d’un projet informatique. En effet, ce sont les étapes où les acteurs s’engagent : la maîtrise d’ouvrage accepte, pour des raisons de faisabilité technique, de budget, de délai, de faire réaliser un système qui ne répond pas à 100 % de ses besoins ; elle accepte le budget du projet ; la maîtrise d’œuvre s’engage à réaliser un système défini, ou à fournir des services définis, pour un prix, et dans un délai. Une fois les spécifications validées, il faut : les gérer : conserver et diffuser la documentation associée, apporter les interprétations, les corrections nécessaires ; les utiliser au moment des recettes ; les faire évoluer, au minimum pendant le déroulement du projet, davantage pendant la vie du système.

La réalisation des spécifications se heurte souvent à des difficultés pratiques : volume et complexité des spécifications, qui rendent difficile leur compréhension, la vérification de leur cohérence, et donc leur validation par la maîtrise d’ouvrage ; ambiguïté des spécifications, qui entraîne des incompréhensions et des difficultés au moment de la recette ; instabilité des spécifications pendant le projet ; difficulté des acteurs, tant maîtrise d’ouvrage que maîtrise d’œuvre, à accepter le formalisme nécessaire. La maîtrise de ces difficultés nécessite de la rigueur de part et d’autre, une estimation correcte des charges relatives aux spécifications, et la définition de méthodes et d’outils adaptés pour structurer et établir les spécifications.