Transition digitale de l'entreprise en mode projet : évitez les pièges

Que ce soit la refonte d'un CRM ou d'un SIRH, la mise en place d'un nouvel ERP ou l'acquisition d'une solution métier comportant des fonctionnalités spécifiques dérogeant au standard, tout projet informatique n'est pas sans risque pour la continuité de l'activité du client. Néanmoins, les projets connaissent souvent des dérives dont l'origine est multiple.

A l'approche de difficultés dans l'exécution des prestations, les positions peuvent rapidement se cristalliser et le climat devenir conflictuel lorsque les délais commencent à dériver et que les performances attendues ne sont pas au rendez-vous.

Commence alors une période de trouble pour les parties : Comités de pilotage houleux, compte-rendus à charge, réserves multiples, refus de validation, application des pénalités, suspension des paiements, avenants modificatifs, définition d'un nouveau périmètre contractuel, rallonges budgétaires, mise en demeure, expertise, contentieux, négociation, transaction...

Sans se risquer d'agir par voie d'ordonnance, voici quelques prescriptions bien utiles pour limiter les risques d'échec de vos projets de digitalisation. Une simple piqure de rappel ?

Définissez vos besoins avec précision !

Tout projet informatique implique un travail en amont de qualification des besoins du client. Or, il apparait que cette étape est bien trop souvent négligée en pratique. L'absence de cahier des charges à titre de référentiel, crée un flou dans le périmètre exact des prestations à réaliser. Le client se retrouve alors en peine pour contester le travail de son prestataire lorsque la solution fournie ne remplit pas les objectifs souhaités.

A titre d'illustration récente dans le cadre du développement d'une application mobile selon la méthode Agile, le Tribunal de commerce de Paris⁽¹⁾ a considéré que les obligations pesant sur le fournisseur dépendaient des besoins et objectifs spécifiques du client, à condition qu'il les exprime précisément. Or, dans cette affaire, les juges ont considéré que le prestataire avait correctement exécuté ses obligations, alors même que le client n'avait pas précisément exprimé ses besoins et qu'il avait validé et payé les livrables fournis, sans émettre de réserves.

Ne négligez pas votre obligation de collaboration !

La réalisation d'une solution informatique implique nécessairement une communication soutenue entre les parties et en particulier la collaboration du client. Celui-ci, sur la base d'un cahier des charges annexé au contrat, doit participer aux différentes étapes du projet, ce qui implique de valider les spécifications réalisées par le prestataire.

Beaucoup de projets échouent en pratique en raison d'un flottement lors de cette phase (défaut de réalisation par le prestataire/absence de validation par le client). Malheureusement, le rythme et les impératifs du projet font que, des solutions de contournements vont être recherchées pour pallier certains manquements et ne pas impacter trop fortement le calendrier, le budget et les équipes en place. Si la recherche de solutions alternatives fait partie du quotidien du projet, il faut être attentif, voire refuser certaines solutions proposées par le prestataire qui écarteraient le client du référentiel technique et des performances attendues, telles que convenues dans le contrat.

Dans un arrêt récent, la Cour d'appel de Paris a rappelé que la phase de recette ne pouvait intervenir en l'absence de spécifications fonctionnelles établies par le prestataire, celles-ci constituant le seul moyen pour le client de s'assurer de la conformité du produit⁽²⁾.

Ainsi, l'obligation de collaboration du client va se matérialiser par son implication constante lors de toutes les phases du projet et une vérification rigoureuse des livrables fournis par son partenaire. En pratique, le client se doit de participer aux comités de pilotage, afin d'identifier les dysfonctionnements, pointer les anomalies et surtout maintenir une communication régulière entre les parties.

Soyez attentifs à la procédure de recette mise en place !

Si l'organisation d'une procédure de recette est aujourd'hui encadrée par la plupart des contrats portant sur des projets informatiques, les clients doivent rester attentifs aux modalités de mise en oeuvre de cette phase cruciale qui marquera la bascule de la solution pour une exploitation en production.

Parmi les principaux enjeux, la réalisation de tests préalables par le prestataire avant toute livraison au client doivent impérativement être stipulée dans le contrat. Ceux-ci seront décrits dans un cahier de recette destinés à vérifier que les livrables sont bien conformes aux spécifications validées entre les parties.

L'accord intervenant entre les parties précisera également les conditions dans lesquelles le client validera la solution fournie. Cette nouvelle étape déterminante se traduira par la conduite de tests destinés à vérifier si la délivrance du produit est conforme au regard des niveaux de performance attendus figurant au contrat. Ce n'est qu'à l'issue de cette phase que la solution fournie devrait être mise en exploitation en conditions de production.

Bien que la jurisprudence retienne depuis longtemps que la signature d'un procès-verbal de recette sans réserves ne suffit pas à établir la conformité d'un produit au contrat⁽³⁾, le client se doit d'être particulièrement vigilant dans le suivi du processus de validation des livrables, les juges pouvant refuser, au regard de l'attitude même du client (absence de protestation dans ses échanges avec le prestataire, absence de tests, cahier des charges imprécis, paiement des prestations) d'invalider une solution qui ne répondrait pas aux promesses attendues en début de projet.

Pour en savoir plus

Antoine Gravereaux est avocat associé du département " Propriété intellectuelle-Technologies-Data " de DS Avocats. Il apporte son expertise sur les problématiques contractuelles liées à l'externalisation d'activité essentielles pour le secteur bancaire au regard de la règlementation applicable et aux contraintes imposées par le régulateur, et plus généralement sur la dématérialisation des opérations des activités de banque.

[1] Tribunal de commerce de Paris, 7 oct. 2020 (n°2019047322)

[2] CA Paris, 26 juin 2020, n°17/20843

[3] Cour de cassation, ch. commerciale, 26 nov. 2013 (n°12-25.191) ; Cour de cassation, 1^re ch. civile, 17 déc. 1991 (n°88-20.406)