Contrat de prestation de services informatiques : à quoi faire attention ?
Une tendance venue des États-Unis pousse à l'inflation des contrats entre prestataires et clients. Mais est-ce vraiment pertinent ? Et surtout, à quoi faut-il faire attention dans son contrat de prestation de services informatiques lorsqu'on est client ? C'est l'objectif de cet article !
Précaution de lecture : nous ne sommes pas juristes, loin de là, mais nous avons une certaine habitude des pratiques réelles du terrain.
Constat de départ : le recours à la justice est rare dans l'informatique !
Premier constat : en 20 ans de travail dans l'IT, il est très, très rare qu'un arbitrage se fasse devant un juge. Et pourtant, les problèmes en informatique – bugs, retards de planning, dérapages – font partie du quotidien. Malgré cela, le recours à la justice reste exceptionnel.
Il y a donc plusieurs enseignements à en tirer :
- Croire qu'un contrat de prestations de services informatiques protège des aléas des projets informatiques est une erreur fréquente.
- Croire qu'un contrat juridiquement « blindé » permettra de défendre ses droits devant un juge est vrai en théorie, mais très rarement vérifié en pratique.
Alors, que faire ? Partir sans contrat de prestation de services informatiques ?
Bien sûr que non ! Mais alors, qu'est-ce qui est vraiment pertinent ?
Il faut d'abord réfléchir à l'objectif du contrat. Quels risques voulez-vous réellement couvrir ? Retards de planning ? Problèmes de qualité ? Malfaçons ? Ce sont souvent les premières idées qui viennent… et pourtant, d'expérience, ce ne sont pas les plus critiques.
Pourquoi ? Parce qu'un projet informatique est relativement court comparé à la durée d'exploitation de la solution. Pour quelques mois de développement, vous allez exploiter l'application pendant plusieurs années (en tout cas, on vous le souhaite !).
Cadrer l'exploitation, plus que le développement
Il est donc plus important de cadrer l'exploitation du logiciel, que son développement initial. Et surtout, de prévoir les conditions qui feront que la relation se passe bien sur le long terme.
Imaginez : vous créez un contrat de prestation de développement très strict, avec des pénalités lourdes pour le moindre retard. Il risque d'arriver deux choses :
- Le prestataire va sacrifier la qualité pour respecter les délais et le budget.
- Il va chercher à se rattraper sur la maintenance.
Et une maintenance de mauvaise qualité (trop chère, mal faite), c'est l'assurance de devoir jeter le logiciel bien plus tôt que prévu.
À quoi faut-il faire attention dans le contrat de prestations de services informatiques ?
Voici quelques points essentiels à vérifier :
- La propriété des codes sources : c'est la règle numéro 1. Si ce que vous faites développer ne vous appartient pas, vous êtes fichu à moyen terme. C'est une erreur très courante. Si vous vous fâchez avec le prestataire, aucun autre ne pourra reprendre. Assurez-vous de posséder les sources et de pouvoir les récupérer à tout moment.
- La transparence sur les technologies utilisées : y a-t-il des licences ou des briques logicielles au régime juridique flou ? C'est essentiel pour comprendre ce qu'il y a dans votre application, notamment en vue de la maintenance.
- La maintenabilité de l'application : le contrat de maintenance doit indiquer comment sont faites les mises à jour des librairies et technologies. Sans cela, vous risquez de vous retrouver 10 ans plus tard avec une appli figée, impossible à faire évoluer sans tout re-développer.
- Des SLA (Service Level Agreements) pour la TMA (Tierce Maintenance Applicative) : ils permettent d'aligner les attentes sur les délais de correction, par exemple. Plutôt qu'imposer des pénalités financières (souvent contre-productives), vous pouvez prévoir des contreparties positives, comme des jours de développement offerts. C'est gagnant-gagnant : le client est satisfait, et le prestataire ne se sent pas puni.
Le contrat de prestation informatique est un filet de sécurité
Ce sont là quelques conseils clés pour bien écrire un contrat de prestation de services informatiques. Ces points doivent toujours être validés conjointement par les deux parties.
Dernier conseil : un contrat doit être compris par tous. Sinon, il ne remplit pas son rôle de garde-fou. On ne devrait jamais avoir à "utiliser" le contrat de prestation informatique : c'est un filet de sécurité, pas un outil de confrontation. Si on doit l'activer, c'est souvent que la relation est déjà compromise.
Et pour que ce soit bien clair : oui, il faut un contrat de prestation de services informatiques, mais un contrat bien fait !
Nos podcasts en lien
Pour aller plus loin
SLA informatique : les bonnes pratiques pour sécuriser les applications dans les contrats !
Quand vous faites des appels d'offres ou des contrats de maintenance applicative, vous devez réfléchir aux délais d'intervention en cas de problème sur votre application : SLA Informatique ! Qu'est-ce qu'une SLA ? Pourquoi en inclure dans ses contrats de maintenance applicative et comment les rédiger ? Les réponses ci-dessous !
Scripts OJS : utilisation des paramètres P5
Quelle est la syntaxe à utiliser pour appeler ou modifier un paramètre OPX2 ?
Architecture SI : 10 commandements pour les DSI
Optimiser l’architecture de son SI, ce n’est pas une mince affaire… Vous connaissez peut-être déjà l’analogie qui compare les systèmes d’information à des villes. De la même manière que l’un des enjeux de l’urbanisme réside dans l’harmonie parfois précaire entre les vieux bâtiments et les tours flambant neuves, maintenir un SI est avant tout une question d’équilibre entre l’ancien et le neuf. N’étant pas spécialistes du sujet, on ne saurait pas vous dire à quoi devrait ressembler la ville parfaite. Par contre, on peut vous assurer qu’un bon SI est un SI avec une architecture maîtrisée qui répond aux besoins de l’entreprise, et qui maximise les fonctionnalités tout en réduisant les coûts.
Nous suivre, nous écouter
