Qui n'a pas été témoin de l'échec d'un projet informatique ? On peut longtemps disserter sur le sens d'échec. Est-ce qu'une augmentation de 15% du prix projeté constitue un échec ? Quid d'un retard de deux mois sur un projet qui en compte six ?

Il n'y a pas de réponse standard. Là n'est cependant pas le propos de ce billet. Plus intéressante est la question de savoir si tous les échecs doivent être logés à la même enseigne et s'il faut se limiter dans nos contrats informatiques à ne gérer, en dehors des pénalités de retard, que les situations extrêmes pouvant ou devant conduire à la résolution du contrat.

Une réflexion sur l'échelle des échecs

Certaines circonstances peuvent venir tempérer la notion d'échec dans un projet informatique :

- Le projet peut être découpé en points fonction. La réalisation du projet se fait progressivement par validations successives de sous-ensembles fonctionnels cohérents mais techniquement indépendants ;

- La reprise en mains du projet est possible par les équipes du client et facilitée par une maîtrise de la solution cible ;

- Certains sous-ensembles fonctionnels réalisés interopèrent déjà avec le système d'information du client ;

- La technologie utilisée n'est pas propriétaire, elle peut être mise en œuvre, gérée ou maintenue par tous prestataires ;

- Le projet n'a pas encore provoqué de rejet au sein de la maîtrise d'ouvrage, etc.

Sur le plan contractuel, il est possible d'écrire un seuil d'acceptabilité d'une solution informatique et d'en anticiper les conséquences, dont une éventuelle réduction du prix, le remboursement d'un trop perçu, l'intervention d'un tiers, l'évolution imposée de la prestation, un dédommagement, etc.

On peut ainsi imaginer qu'en deçà d'un certain seuil, la résolution de plein droit du contrat pourrait être automatique avec les effets rétroactifs associés.

Dans une tranche comprise entre 60 % et 90 %, la liberté serait donnée au client de prononcer la résolution (avec restitution du prix payé) ou la résiliation de plein droit (qui ne produit effet que pour l'avenir), selon la capacité d'utilisation de la solution en l'état chez le client, appréciée à dire d'expert.

Au-delà de 90 %, priorité serait donnée à la continuation du projet ou à son arrêt moyennant une réfaction du prix, à la discrétion du client. La difficulté serait d'établir une base de calcul objective de ce pourcentage au regard du projet concerné.

En cas de reprise du projet par le client ou un tiers mandaté par lui, le client se verrait consentir automatiquement par le prestataire défaillant un droit d'utilisation élargi aux sources documentées du progiciel et des développements concernés aux fins de finalisation du projet, par lui-même ou par un tiers.

Une réflexion sur l'échelle des sanctions

Un système clé en mains ne peut se comprendre que comme un tout indivisible. Il sera conceptuellement difficile de le compartimenter en cas d'échec. La logique de la résolution, et donc de la restitution du prix, s'impose a priori.

Il en irait de même de l'échec d'un projet mené par l'éditeur lui-même, avec une solution progicielle propriétaire manquant de robustesse, ou de celui conduit par un prestataire chargé du développement puis de la gestion ultérieure de ladite solution pour le compte de son client.

Mais même dans ces hypothèses, à partir de quand et comment déterminer qu'un projet ne serait pas récupérable ?

Pourquoi ne pas le prévoir en traitant contractuellement les facteurs d'échec ?

L'indisponibilité, connue du prestataire, des équipes du client au-delà d'un certain retard peut être un facteur déterminant pour qualifier d'irréversible une dérive de projet. De même, quand le progiciel constituant le cœur de la solution cible est en cause, il est inutile de s'entêter.

En revanche, l'incompétence de l'équipe de projet du prestataire, constatée à temps, peut dans certains cas être gérée moyennant un changement d'équipe, voire l'intervention d'un tiers spécialiste de la gestion de projets aux frais du premier.

De nouveau, la mesure et la contractualisation des enjeux, priorités, objectifs et contraintes constituent un bon conducteur pour établir une hiérarchie des éléments déterminants et les sanctions adaptées à la criticité de la situation en résultant.

Ce sont eux qui permettront d'associer au non-respect d'une obligation une échelle de sanctions allant jusqu'à la résolution du contrat, bref un permis à points contractuel.

Lorsque le seuil d'échec défini contractuellement sera atteint, le prestataire « perdra » son permis et le client acquerra la faculté de résolution de plein droit du contrat.

Une reconstitution de points sera possible, avant d'atteindre ce seuil, quand le prestataire aura fait preuve d'ingéniosité ou aura accompli des efforts importants pour remettre le projet sur des rails dans les délais.

Coller au plus près de la réalité opérationnelle du projet, dès la rédaction du contrat, n'est-elle pas « La » solution pour réduire le risque de contentieux traditionnellement très coûteux et aléatoires ?

Hervé Gabadou,

avocat associé, département informatique & réseaux du cabinet Courtois Lebel