Les écueils à éviter lors de la négociation d'un contrat informatique
Publié par Hervé Gabadou le | Mis à jour le
A chaque fois que se profile une crise, la tendance est à une réduction massive des dépenses. La fonction informatique de l'entreprise n'y échappe pas. Certains projets informatiques sont abandonnés, les plus stratégiques ou les moins coûteux sont conservés. Et c'est là que l'avocat intervient... souvent trop tard.
L’histoire se répète. Plusieurs erreurs sont à l’origine de cette situation et parmi les plus récurrentes, on citera :
- Alors que l’informatique est toujours plus au service des métiers (architecture SOA, les XaaS, etc.), les contrats restent souvent entre les mains des acheteurs seuls. La maîtrise d’ouvrage, qui va devoir suivre et exécuter le contrat, est la grande oubliée de la négociation. Les fonctions concernées de l’entreprise devraient y être représentées, et pas seulement les achats auprès de qui tous les enjeux n’ont pas été nécessairement communiqués préalablement. Une démarche transversale s’impose pour éviter une approche uniquement guidée par les coûts, pouvant s’avérer gravement contreproductive pour la suite du projet.
- Un contrat trop déséquilibré. Trop de protection juridique au moyen d’engagements irréalisables crée une vulnérabilité, facteur de risques, qui se retourne contre celui qui croit en bénéficier.
- Proche du précédent écueil, l’absence de collaboration est l’idée fausse selon laquelle la responsabilité contractuelle pourrait se substituer à la responsabilité d’une tâche. Il faut être deux pour réaliser un projet : l’absence de collaboration du client ne pourra jamais être remplacée par un engagement fort du prestataire, et vice versa.
- L’absence de précision quant à la détermination des responsabilités opérationnelles. Lorsque les rôles et responsabilités sont mal définis au sein du contrat, il s’ensuit des difficultés qui peuvent conduire à une situation contentieuse.
- Une mauvaise expression des besoins et son corollaire, un devoir de conseil défaillant, voire un silence coupable du prestataire, dans des cas extrêmes. Même s’il est usuel que les besoins s’affinent durant la phase de cadrage des besoins, il y a souvent débat, voire litige, sur la largeur ou la profondeur du périmètre de référence. La réception d’un projet confirme que le prestataire a rempli son obligation de délivrance conforme. La détermination du référentiel de conformité doit donc être particulièrement soignée avant de conclure le contrat.
- L’absence de détermination et de contractualisation des objectifs, des contraintes, des enjeux qui définissent à leur tour les priorités. Ces dernières seront les « juges de paix » pour les arbitrages qui s’avéreront nécessaires durant le projet.
- L’impréparation ou l’indisponibilité des équipes : une phase précontractuelle bien menée doit permettre de déterminer les contraintes du projet. Il peut être urgent d’attendre avant de signer.
- L’incompétence des équipes affectées au projet, notamment au regard de la technologie déployée. Une attention particulière devra être portée sur la qualité des équipes affectées au projet au regard de ses enjeux, avant de s’engager.
- La défaillance dans le pilotage du projet. Le changement de méthodologie en cours de projet, souvent de manière insidieuse, est une cause quasi inéluctable de dérive grave de projet. Autant se la faire préciser avant de contracter.
- Des problèmes de fiabilité et de qualité des données. Souvent omises dans la phase précontractuelle et durant la conduite du projet, la mauvaise intégration des données peut provoquer le rejet par les utilisateurs d’un nouveau système et conduire à un différend.
Avant de conclure le contrat, il serait avisé de consacrer plus de temps à réfléchir sur les risques, les contraintes et objectifs du projet, de les contractualiser, pour finalement réduire les risques d’un contentieux par essence coûteux.
