Tronc commun / CEJM / CEJM appliqué — Contrats et services informatiques

CEJM appliqué — Contrats et services informatiques

Module CEJM appliqué. Savoir lire un contrat de prestation informatique et repérer les clauses qui engagent réellement les parties.

1. Typologie des contrats

Deux modes d'engagement à distinguer :

2. Moyens ou résultat

C'est la question la plus discriminante d'un cas pratique. Ne pas la trancher au hasard : chercher dans l'énoncé si le contrat promet un résultat mesurable (un taux de disponibilité, une date de livraison) ou seulement des compétences mises en œuvre. Le régime détermine ensuite qui supporte la charge de la preuve, et donc l'issue du litige.

3. Devoir de conseil et collaboration

Le prestataire informatique est un professionnel face à un client souvent profane. Il en découle un devoir de conseil renforcé, dégagé par la jurisprudence :

• Informer sur les caractéristiques et les limites de la solution ;
• Se renseigner sur les besoins réels du client, sans se contenter de sa demande brute ;
• Mettre en garde contre les risques : sous-dimensionnement, incompatibilité, dette technique ;
• Déconseiller une solution inadaptée, même si le client la réclame.

Symétriquement, le client a une obligation de collaboration : exprimer clairement son besoin, fournir les informations et les accès, désigner un interlocuteur, participer à la recette. Un client qui ne collabore pas voit sa propre responsabilité engagée, ce qui atténue celle du prestataire.

La recette (ou vérification d'aptitude) est l'étape où le client valide la conformité de la livraison. Elle est décisive : la recette sans réserve fait généralement courir la garantie et transfère la charge des anomalies ultérieures.

4. Les SLA

SLA (Service Level Agreement) = engagement de niveau de service, avec des indicateurs mesurables et des pénalités en cas de manquement.

Ce qu'un pourcentage de disponibilité représente réellement sur une année :

Points à vérifier absolument : la méthode de mesure (qui mesure, avec quel outil), les exclusions (maintenance planifiée, force majeure, défaillance du réseau du client), et le plafond des pénalités. Des pénalités plafonnées à 5 % de la redevance mensuelle ne compensent pas une journée d'arrêt de production — c'est le point que l'on attend de toi en analyse critique.

Lien direct avec le B3 : les engagements de GTR doivent être cohérents avec le RTO défini au plan de reprise d'activité. Un RTO de 4 h avec un prestataire engagé sur une GTR de 24 h est une incohérence.

5. Les contrats cloud

Cette répartition détermine le partage des responsabilités, y compris en sécurité : en SaaS, le client reste responsable de la gestion de ses comptes et de ses droits, même si l'infrastructure ne lui appartient pas.

En SaaS, le client n'achète pas le logiciel : il acquiert un droit d'usage, pour une durée déterminée. Il n'a ni le code, ni la maîtrise des mises à jour, ni la garantie de pérennité du service. D'où l'importance des clauses de sortie.

6. Les clauses à vérifier

La clause de réversibilité est celle qu'on oublie à la signature et qu'on regrette à la sortie. Sans elle, le client se retrouve captif : données dans un format propriétaire, coût de migration prohibitif. C'est la traduction juridique du risque de vendor lock-in vu au thème 4.