NUMÉRIQUE

Contrats informatiques, des contrats pas comme les autres

Publié dans l'édition Nord N. 8767 par

Les technologies issues du numérique (logiciels, bases de données…) ont donné naissance à des contrats qui nécessitent une approche particulière et posent parfois des difficultés en raison de la complexité technique de la matière et de la diversité des besoins à satisfaire. Et leur réalisation implique souvent une gamme étendue de prestations et une diversité […]

Vous devez être connectés pour visualiser cet article

D.R.

Les technologies issues du numérique (logiciels, bases de données…) ont donné naissance à des contrats qui nécessitent une approche particulière et posent parfois des difficultés en raison de la complexité technique de la matière et de la diversité des besoins à satisfaire. Et leur réalisation implique souvent une gamme étendue de prestations et une diversité des intervenants.

Parmi les spécificités des contrats relatifs à l’informatique, une place centrale est occupée par l’obligation de conseil du fournisseur, qui doit cependant être interprétée en lien avec son complément, le devoir de collaboration du client.

L’obligation renforcée de conseil du professionnel… L’”informaticien” est un professionnel. Comme tel, il est soumis tant à certaines diligences particulières qu’à un renforcement de ses obligations. En particulier, quant à l’obligation de renseignement ou d’information. La Cour de cassation a formulé la règle de façon très claire : “Le vendeur professionnel d’un matériel informatique est tenu d’une obligation de renseignement ou de conseil envers un client dépourvu de toute compétence en la matière” (Com. 11 juillet 2006, n° 04-17). Le devoir de conseil implique que le fournisseur s’informe des besoins de son client. Il englobe aussi celui de recommander au client de modifier, le cas échéant, les structures de son entreprise et de former son personnel, de l’éclairer sur les conséquences des choix qu’il effectue, par exemple sur la nécessité de souscrire un contrat de maintenance et “d’actualiser” l’installation, ou sur l’incompatibilité du matériel fourni avec l’installation existante. Il comporte encore celui de mise en garde, par exemple contre les insuffisances du cahier des charges ou les difficultés d’installation du système envisagé. Dans toutes ses modalités, l’obligation de conseil est réputée être traditionnellement une obligation de moyens et non de résultat, notamment parce que le client demeure responsable de ses choix. Cependant, certains arrêts retiennent un régime juridique intermédiaire entre ceux de l’obligation de moyens et de résultat : on peut alors parler d’une obligation de moyens renforcée.

… ajustée aux compétences du client. Toutefois, le client doit, de son côté, se renseigner, surtout s’il est lui-même un professionnel. Au fond, seule son ignorance légitime est recevable. Autrement dit, la qualité du client influe sur l’intensité du devoir de conseil. Il sera moindre envers une personne assistée d’un conseil professionnel qu’à l’égard d’un profane. Le devoir de collaboration pesant sur le client devient ainsi un trait caractérisant les contrats informatiques. Dans ce domaine il est plus puissant et fréquent que dans d’autres, les contrats relatifs à l’informatique étant souvent marqués d’un certain intuitu personae. L’obligation de coopération donne parfois lieu à une clause spécifique ou à une annexe au contrat, organisant ses modalités et ses organes. Les besoins spécifiques du client peuvent ainsi être précisés à l’aide d’un cahier des charges, en droit théoriquement facultatif, en fait pratiquement obligatoire en la matière dès que les prestations envisagées sont un peu complexes.

Un possible déséquilibre des relations entre le prestataire et le client. Il faut par ailleurs noter que ce devoir de collaboration du client continue dans l’exécution même du contrat. Surtout, dans des contrats sur une longue durée, il est parfois envisageable d’en renégocier les conditions lorsqu’elles deviennent déséquilibrées à la suite d’un changement des données. Cela, à défaut même d’une clause de dureté (hardship), en raison de la bonne foi devant guider les parties. D’autre part, les usages de l’informatique tolèrent une certaine marge de difficultés, notamment pendant la période de mise au point. Face à ces contraintes, s’avère encore plus forte la nécessité d’identifier un “architecte” pour la “construction de l’ouvrage”, juridiquement connu comme maître d’œuvre. Le concept de “maîtrise d’œuvre” est, en l’état de la technique contractuelle, utile voire incontournable pour répondre aux différents enjeux portés par les spécificités de ces contrats, même auprès des clients/maîtres d’ouvrage dotés d’une équipe projet structurée et bien conseillée par des assistants à la maîtrise d’ouvrage (AMOA). Néanmoins, on constate une tendance forte du marché, surtout de la part d’intégrateurs de grande taille, puissants sur leur marché, à se mettre en retrait de leurs engagements juridiques.

Une nécessaire adaptation dans le temps de la relation contractuelle. Au vu de difficultés connues par les projets informatiques, et face à une forme de défiance envers le modèle “classique” de contractualisation, de nouvelles pratiques, opérationnelles et juridiques, sont apparues sur le marché. Ainsi, la méthode de contractualisation “Agile” invite à appréhender différemment la négociation contractuelle et la gestion des projets informatiques, dans une démarche collaborative entre le client et le prestataire. Le principe est d’adopter un modèle contractuel qui fixe le délai et le coût en fonction de la valeur à produire, en faisant varier le périmètre fonctionnel, afin de maximiser la valeur produite dans le temps, en suivant le rythme des changements. Selon ce modèle contractuel Agile, le projet doit permettre d’atteindre un seuil minimum de valeur acquise, lequel peut d’ailleurs fluctuer au cours de l’avancée du projet. Cette méthode permet l’intégration du changement dans la mécanique contractuelle. Le projet peut s’arrêter à chaque moment, en produisant toujours un seuil minimum de valeur, et précisément celle que le client estime la plus adapte au rapport temps/coûts. Sur le plan juridique, le contrat doit sortir des mécanismes classiques pour adopter une approche centrée sur la création de valeur. Ainsi, l’articulation entre un contrat-cadre et des contrats d’application permet de définir les droits et obligations des parties, dans le cadre d’un pilotage qui privilégie la réalité opérationnelle

Le contrat-cadre Agile. Sont définis au titre contrat-cadre les clauses contractuelles générales, la gouvernance et les mécanismes de gestion du changement. La collaboration entre les parties est imposée aussi du fait que les changements peuvent être à l’initiative du client comme du prestataire. Le contrat-cadre détermine ainsi la capacité à produire du prestataire, avec une marge de manœuvre suffisante pour absorber les changements, sans nécessité de renégocier le contrat. Les dispositions concernant la durée du contrat, les cas de sortie et les conséquences de la résiliation du contrat sont également fixées par le contrat-cadre. Le contrat d’application formalise une valeur cible, valorisée en cost of delay, ainsi qu’une valeur minimum à produire. Grâce à cette méthode, le projet s’inscrit dans une temporalité faite de courtes itérations qui permet la sortie du projet, en fonction de la valeur créée1. Cette méthode témoigne enfin du défi que la contractualisation doit relever pour appréhender au mieux son virage vers l’ère numérique.

Charles DELAVENNE, avocat associé (cdelavenne@dlga.fr) et Giovanna Andrea LICATA, , avocate au barreau de Rome et Lille (glicata@dlga.fr)Lille (glicata@dlga.fr),