Un contrat d'infogérance paraît souvent complet tant qu'aucun incident sérieux n'a lieu. C'est au moment où une sauvegarde échoue, où un compte administrateur manque ou où un prestataire sortant doit transmettre les accès que les zones floues deviennent visibles.
Le vrai rôle du contrat n'est pas de formaliser une intention générale. Il sert à empêcher les malentendus opérationnels. Un bon contrat rend le service lisible avant que les tensions apparaissent.
Le problème réel
Une part importante des désaccords vient d'un périmètre mal défini. Le prestataire pense intervenir sur certains éléments. Le client pense en avoir acheté davantage. Entre les deux, il n'existe souvent ni liste d'actifs, ni matrice de responsabilités, ni définition précise des exclusions.
Plus le contexte est critique, plus cette imprécision coûte cher. Un incident n'interrompt pas seulement un service informatique. Il révèle tout ce qui n'avait pas été écrit.
Ce qu'un contrat doit absolument contenir
Le périmètre exact
Le contrat doit lister les actifs pris en charge. Postes, serveurs, switchs, firewall, bornes Wi Fi, NAS, Microsoft 365, tenant cloud, sauvegardes, téléphonie et équipements distants doivent être identifiés sans ambiguïté. Une formule générique du type environnement informatique n'a pas de valeur opérationnelle.
Les exclusions
Les exclusions doivent être explicites. Elles évitent de découvrir trop tard que les licences, le réseau opérateur, les équipements personnels, les interventions hors site ou certaines applications métiers ne faisaient pas partie du service.
Les rôles et responsabilités
Une matrice simple permet d'indiquer qui fait quoi. Qui crée les comptes. Qui valide les droits. Qui décide d'une coupure de service. Qui pilote une restauration. Qui gère la relation avec un éditeur logiciel. Sans cette matrice, la responsabilité se dilue précisément au moment où elle devrait être la plus claire.
Les niveaux de service
Le contrat doit renvoyer vers des engagements mesurables. Délai de prise en charge, délai de résolution, plage horaire couverte, niveau de disponibilité et modalités de priorité selon la criticité des incidents. Le sujet des SLA mérite d'ailleurs un cadrage dédié tant il est souvent mal compris.
Les modalités de sauvegarde
Le contrat doit préciser ce qui est sauvegardé, à quelle fréquence, avec quelle rétention et selon quel niveau de test. Le guide d'hygiène informatique de l'ANSSI insiste sur la nécessité de restaurations de contrôle. Sans vérification, il n'existe pas de preuve opérationnelle que la sauvegarde permet réellement une reprise.
La sécurité et les accès
Le contrat doit préciser la gestion des comptes privilégiés, l'usage éventuel d'outils d'administration à distance, la journalisation, le chiffrement, l'authentification multifacteur lorsque le contexte l'exige et les conditions d'accès au système d'information par le prestataire.
La sous traitance
Une partie du service peut être opérée par un tiers. Support de nuit, supervision, SOC, hébergement, sauvegarde externalisée. Cette sous traitance n'est pas en soi un problème. Elle doit simplement être connue, encadrée et contractuellement visible.
La réversibilité
Le contrat doit définir dès le départ les conditions de sortie. Restitution des mots de passe, documentation, exports, inventaire, états de sauvegarde, licences, paramètres réseau, scripts d'automatisation et calendrier de transition. La réversibilité est un sujet trop important pour être traité en annexe de fin de relation.
Une structure contractuelle qui fonctionne bien
Un contrat lisible suit généralement la logique suivante.
- Objet du contrat.
- Périmètre des actifs et services.
- Exclusions.
- Gouvernance et responsabilités.
- Niveaux de service.
- Sauvegardes et continuité.
- Sécurité et confidentialité.
- Réversibilité.
- Facturation et conditions d'évolution.
Cette structure a un avantage simple. Elle place le fonctionnement réel avant les aspects purement administratifs. Elle rend la lecture plus utile pour les équipes opérationnelles.
Ce qui relève du contrat principal et des annexes
Le contrat principal fixe généralement les principes, les responsabilités, la durée, la gouvernance et les règles de sortie. Les annexes portent plus utilement le détail opérationnel. Inventaire des actifs, niveaux de service détaillés, règles de sauvegarde, contacts d'escalade, liste des sites ou procédures de transition trouvent souvent une place plus stable dans ces annexes. Cette séparation facilite les mises à jour sans fragiliser l'ensemble contractuel.
Un exemple tres simple de clause utile et de clause faible
Une clause faible ressemble a ceci. Le prestataire assure la sauvegarde des donnees du client. Cette phrase semble claire, mais elle laisse ouvertes les vraies questions. Quelles donnees. A quelle frequence. Avec quelle retention. Avec quel niveau de test. Dans quel delai de reprise.
Une clause plus utile decrit le perimetre sauvegarde, la frequence, la retention, le principe de verification et les conditions d'escalade en cas d'echec. La difference de longueur parait minime. La difference de valeur operationnelle, elle, est considerable.
Les clauses à surveiller de très près
Les formulations trop larges
Une formule qui promet la maintenance globale du système d'information paraît rassurante. Elle devient peu utile si rien n'indique quels actifs sont réellement inclus.
Les obligations sans méthode de preuve
Dire qu'un prestataire assure les sauvegardes ou la sécurité n'a de valeur que si le contrat précise comment cela est vérifié. Rapports périodiques, revues, traces, comptes rendus de test ou inventaires font partie de cette preuve.
Les évolutions de périmètre implicites
Dans une PME, le parc change vite. Nouveaux utilisateurs, nouveaux sites, nouvelles licences, nouveaux services cloud. Le contrat doit prévoir la façon dont le périmètre évolue et comment la facturation suit cette évolution.
Les clauses de sortie trop faibles
Une sortie sans calendrier, sans format de restitution et sans livrables nommés devient souvent un transfert chaotique. Une sortie propre se prépare dans le contrat initial. Elle ne se négocie pas dans l'urgence.
Les annexes qui apportent le plus de valeur
- Inventaire des actifs pris en charge.
- Annexe SLA avec niveaux de criticite.
- Regles de sauvegarde et de verification.
- Modalites de reversibilite et livrables attendus.
Ces annexes n'alourdissent pas inutilement le contrat. Elles deplacent au contraire le detail la ou il devient le plus exploitable.
Les erreurs fréquentes
Signer avant l'inventaire
Sans inventaire fiable, le contrat repose sur une approximation. Cette approximation finit presque toujours par produire un écart entre ce qui est attendu et ce qui est opéré.
Négliger les applications métiers
Beaucoup de contrats décrivent correctement l'infrastructure mais oublient les applications critiques. Or c'est souvent là que se situent les plus fortes dépendances métier.
Oublier la conformité liée aux données
Dès qu'un prestataire agit comme sous traitant au sens du RGPD, le cadre contractuel doit intégrer les exigences liées au traitement des données personnelles. La CNIL rappelle que ces obligations doivent être décrites dans le contrat de sous traitance.
Ce que cela change concrètement
Un contrat mieux construit réduit les zones d'interprétation. Il simplifie le pilotage, améliore le niveau de preuve et réduit le risque de conflit au moment où les équipes sont déjà sous pression.
Il permet aussi de comparer les offres sur une base utile. Tant que deux prestataires ne répondent pas au même périmètre et aux mêmes engagements, leurs devis ne sont pas réellement comparables. Un diagnostic ou un travail de cadrage préalable permet de poser ce socle avant consultation.
Sources
- CNIL Sous traitance des données personnelles et contrat
- ANSSI Guide d'hygiène informatique
- NIST Cybersecurity Framework
Sources
Accompagnement disponible sur ce sujet
Initial Infrastructures intervient sur l'ensemble de ces problématiques pour les PME et ETI. Un échange court permet d'identifier les priorités et le bon niveau d'intervention.