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 (...)
