Mettre en production une solution dans les délais prévus, avec la couverture fonctionnelle souhaitée et dans le respect du budget ; délivrer le service aux utilisateurs avec les performances requises : la qualité est au cœur des préoccupations du chef de projet ou du responsable de production. Nous souhaitons souligner dans cette chronique le rôle essentiel du contrat comme outil de pilotage de cette qualité à atteindre.
De la nécessaire définition du niveau de qualité attendu
La qualité n’est pas une notion juridique. Le droit parle « d’obligations », de « réception », de « responsabilité » : un prestataire va s’obliger vis-à-vis d’un client à fournir une prestation, que le client va réceptionner, c’est-à-dire déclarer conforme ou non, ce qui dans ce dernier cas pourra entraîner une responsabilité et une indemnisation.
Lorsque le juriste entend « qualité », il pense d’abord à la « normalisation ». La normalisation est un processus qui, dans le cadre d’une instance de normalisation, conduit à l’expression par consensus du meilleur état de l’art sur une question technique ou organisationnelle. L’atteinte d’un certain niveau de qualité est l’un des objectifs de la normalisation.
La normalisation s’opère dans un cadre juridique précis. En France, c’est l’AFNOR, association loi 1901 délégataire d’une mission de service public, qui est en charge d’organiser le processus de la normalisation. Au plan international, c’est l’ISO qui assure le développement des normes.
Lorsque l’on regarde les chiffres disponibles de l’ISO, publiés fin 2011, on s’aperçoit qu’il y a finalement assez peu de normes dans le domaine du logiciel ou du service informatique comparativement à d’autres domaines techniques.
Le domaine dans lequel les normes sont les plus nombreuses est celui des « techniques de l’ingénieur », avec 5 242 normes. Ensuite viennent les technologies des matériaux, avec 4 460 normes et en troisième position l’électronique et les technologies de l’information et de la communication avec 3 186 normes. Dans ce dernier domaine, si l’on retire les normes qui concernent l’électronique et les télécommunications, la partie relative aux logiciels ou services informatiques est assez réduite. On peut penser que lorsque l’absence de normalisation obère le développement d’un marché, les acteurs économiques s’entendent sur des normes, notamment pour traiter des problématiques de compatibilité entre produits. La normalisation est plus limitée lorsque le développement du marché n’en pâtit pas.
Il existe cependant des normes dans le domaine informatique dont les plus connues sont l’ISO/CEI 20 000 pour la gestion de services informatiques et l’ISO/CEI 270 01 pour la sécurité? de l’information.
A côté de ces normes « officielles », car prises dans le cadre réglementé d’une instance de normalisation, il y existe de nombreux « standards », « référentiels » ou « best practices » établis en dehors des institutions traditionnelles de normalisation. Les acronymes fleurissent sur ce sujet : ITIL, COBIT, Lean IT, ValIT, CMMI, ABC/ABM, Togaf, eSCM, etc. Ces standards ne sont pas des normes au sens juridique du terme.
Dans un monde de prestations ou de fournitures « non normées », un outil fondamental de maîtrise de la qualité sera le contrat. Le contrat va avoir pour objectif de répondre à cette question essentielle : quel est le niveau de qualité que j’attends d’un produit ou d’un service ?
Si l’on définit la qualité comme le niveau de satisfaction que doit procurer un produit ou un service, il faut constater que ce niveau de satisfaction est nécessairement subjectif. Il n’y a pas de qualité objective dans le domaine informatique. Nous ne sommes pas dans un domaine de la technique dans lequel la qualité d’un produit ou d’un service peut s’apprécier objectivement en référence à une norme de qualité. En matière informatique, les normes ou standards traitent essentiellement de la manière de rendre un service, pas des caractéristiques intrinsèques que doit présenter un produit – par exemple un logiciel – comme c’est le cas dans bien d’autres domaines techniques : BTP, industrie agro-alimentaires, chimie, etc.
La qualité étant subjective, il est nécessaire de la définir, la préciser, la spécifier : il n’y a pas d’alternative. Cette nécessaire définition du niveau de qualité souhaité est non seulement l’intérêt mais aussi l’obligation du client. L’absence de définition claire de ses attentes en terme de qualité par un client bénéficiera toujours au prestataire parce que le client sera en difficulté pour prouver un manquement. C’est dans le contrat que ces réponses doivent être données.
La notion de qualité est vide de sens si l’on ne met pas en regard avec les moyens dont il faut se doter pour l’atteindre et donc leur coût. La qualité c’est le niveau de satisfaction attendu d’un produit ou d’un service pour un prix convenu.
Ce point est évidemment essentiel et une fois encore, il appartiendra au contrat de fixer ce prix, et ce de manière claire : un travail essentiel va être de s’assurer que dans le contrat, à une exigence en terme de qualité, répond un engagement du prestataire et à cet engagement répond un prix.
Le contrat comme outil au service de la qualité
Lorsqu’il n’existe pas de norme définissant ce que constitue la qualité, il convient nécessairement de prévoir ce référentiel dans le dispositif contractuel. Le contrat sera la « norme » de qualité entre les parties. Un soin particulier doit donc être apporté à sa négociation et sa rédaction.
Il en résulte que le versant juridique de la relation avec le fournisseur de service doit être intégré par les personnes chargées dans l’entreprise d’acquérir les produits ou prestations informatiques. Il faut cesser de voir le contrat comme une formalité administrative par laquelle on est contraint de passer, après avoir négocié avec un prestataire et s’être mis d’accord, et alors que l’on a hâte de débuter le projet.
L’enjeu est de faire du juridique un atout et non une contrainte. Or, le juridique devient une contrainte s’il n’est pas anticipé et s’il est subi. Il est frappant de constater qu’en pratique, beaucoup d’entreprises fonctionnent sur un mode de séquençage pour l’achat de leurs prestations informatiques : les métiers et la direction informatique établissent le cahier des charges (pour être moderne, on dira le RFP) ; la direction des achats négocie les prix avec le prestataire, puis on demande au service juridique de s’occuper du contrat. Ce séquençage des rôles conduit invariablement à un contrat inadapté car le contrat informatique est un contrat qui fusionne les aspects techniques, économiques et juridiques. Chacun de ces trois acteurs doit être impliqué au même niveau et en même temps dans la rédaction et la négociation du contrat. Les fournisseurs de services l’ont bien compris. C’est souvent un trinôme technicien, commercial et juriste qui est formé par la SSII, depuis la réponse au RFP jusqu’à la signature du contrat.
L’autre écueil du séquençage est le temps pris par la négociation. Il est ici encore frappant de constater que les entreprises n’anticipent jamais le temps que va prendre la négociation du contrat. Une fois les offres dépouillées, la négociation financière réalisée, la signature du contrat est perçue comme une formalité, qui se déroulerait en un instant de raison, le fameux « kick-off » du projet pouvant être organisé sans délai. Or la réalité est bien différente. Même si la négociation technique et financière est bouclée, la rédaction et la négociation du contrat prendront un temps, que l’on peut efficacement limiter, mais qui demeure incompressible. Il faut l’anticiper dans le planning général de déroulement du projet.
Bon nombre de contentieux sont générés par le fait que les prestations ont débuté en l’absence de contrat signé. Or, débuter un projet avec un contrat signé n’est pas un objectif impossible à atteindre ! C’était même la règle il n’y a pas si longtemps…
Une qualité qui s’appuie sur des engagements réalistes
Une solution conforme, livrée dans les temps, au coût prévu. C’est ce que l’on appelle « the iron triangle ». Le contrat devra élaborer les mécanismes juridiques qui permettent de tenir ces contraintes. Mais les projets informatiques ne se ressemblent pas. Chacun a ses particularités, ses contraintes propres, ses attentes spécifiques. Ceci illustre une nouvelle fois le propos développé plus tôt : le contrat informatique n’est pas une simple formalité. Chaque contrat informatique devra être adapté aux risques spécifiques du projet et le contrat devra anticiper chacun de ces risques spécifiques, par une solution contractuelle adaptée et nécessairement négociée avec le prestataire.
Si l’on examine chacun des côtés de notre « triangle » sous un angle juridique, les contentieux informatiques sont riches d’enseignements.
En termes de délai, le calendrier de déroulement du projet doit être réaliste pour ne pas dire pessimiste. Si l’on demande à un prestataire de respecter des dates impératives de livraison, le cas échéant assorties de pénalités en cas de non-respect, il faut que le client soit aussi vertueux que le prestataire dans le respect de ses propres délais. Les dates impératives et pénalités sont inutiles si le prestataire est en mesure de montrer que leur dépassement vient, au moins en partie, des retards du client dans l’expression de ses besoins ou dans la validation des livrables, par exemple.
Plutôt que de subir cet état de fait, et de signer des contrats stipulant des mécanismes inadaptés, il faut intégrer au calendrier contractuel une marge de sécurité qui permette au client d’absorber ses propres retards, sans pour autant faire tomber les engagements impératifs de livraison du prestataire. Mieux vaut se concentrer sur quelques dates impératives, envisagées comme les dates butoirs maximales auxquelles la solution doit être mise en production, plutôt que sur de nombreux jalons qui sauteront parce que le client n’est pas lui-même en mesure de suivre le rythme du projet.
En termes de prix, le forfait n’est pas la panacée. Le forfait n’évite pas au client d’être efficace dans la réalisation de ses tâches. Le client est finalement tout autant garant que le prestataire de la tenue du forfait. Il est bon de réfléchir à d’autres modes de facturation, notamment pour la phase d’analyse.
En termes de conformité, les contentieux informatiques éclairent également sur l’imprévision des contrats sur les deux éléments essentiels que sont : un référentiel de conformité clair et un mécanisme de recette organisé dès la signature du contrat.
Ce sont des points fondamentaux, qui peuvent paraître basiques, mais tous les projets qui se terminent par un échec, voire un contentieux, ont ceci en commun : ces points avaient été oubliés ou faisaient l’objet de stipulations inadaptées.
* *
Le juridique révèle en réalité bien souvent des failles dans l’organisation d’un projet que l’analyse technique et financière n’avait pas relevé. C’est un prisme de lecture des offres et de management du projet dont il ne faut pas faire l’économie.
