Pendant longtemps, la relation entre une Direction des Systèmes d’Information et les métiers a reposé sur une forme d’évidence. La DSI mettait à disposition des outils, les utilisateurs les consommaient et, tant que tout fonctionnait, personne ne ressentait réellement le besoin de préciser davantage les règles du jeu.
Le système d’information est devenu trop présent dans le fonctionnement quotidien des organisations pour que cette relation continue à reposer sur des implicites. Messagerie, visioconférence, partage documentaire, applications métier, accès depuis des terminaux mobiles, télétravail, services Cloud : l’activité dépend désormais directement d’un ensemble de services numériques dont les contours ne sont pas toujours parfaitement compris par ceux qui les utilisent.
Et c’est précisément là que la convention de service prend tout son sens.
Il ne s’agit pas de produire un document administratif supplémentaire, destiné à prendre place dans une bibliothèque documentaire que plus personne ne consultera six mois plus tard. Une convention bien conçue remplit une fonction beaucoup plus importante : elle explique ce que la DSI fournit, comment elle le fournit, dans quelles conditions, avec quelles limites et, surtout, avec quelles responsabilités de part et d’autre.
Autrement dit, elle transforme une relation parfois implicite entre la DSI et les directions en un véritable « contrat de confiance ».
Un service numérique ne se résume plus à une infrastructure
La transformation numérique et le Cloud ont profondément modifié la nature des services fournis par les DSI. Prenons un exemple aussi banal que la messagerie.
Il y a quelques années, décrire un service de messagerie revenait essentiellement à parler de serveurs, de boîtes aux lettres, de sauvegarde et de capacité de stockage. Aujourd’hui, derrière une boîte aux lettres dans Microsoft 365 se trouvent Exchange Online, Microsoft Entra ID, l’authentification multifacteur, Conditional Access, Microsoft Defender, Microsoft Purview, les terminaux mobiles et, plus largement, tout un ensemble de règles de sécurité, de conformité et de gouvernance.
Pour l’utilisateur, pourtant, tout cela reste souvent résumé par une phrase très simple : « J’ai une boîte mail ».
C’est précisément dans l’espace qui sépare ces deux perceptions que naissent les incompréhensions.
La DSI voit une architecture complexe avec des règles de sécurité, des dépendances, des responsabilités et des limitations. L’utilisateur voit un service auquel il estime légitimement pouvoir accéder lorsqu’il en a besoin.
Les deux ont raison. Mais ils ne parlent tout simplement pas de la même chose. La convention de service permet de créer ce langage commun.
Remplacer les suppositions par des engagements
La plupart des difficultés apparaissent rarement lorsque le service fonctionne normalement. Elles surgissent lorsque l’on rencontre une situation inhabituelle.
Un utilisateur part à l’étranger et découvre que certaines conditions d’accès changent. Un collaborateur pense pouvoir connecter n’importe quel équipement personnel. Une direction considère qu’une information est conservée indéfiniment alors que ce n’est pas nécessairement le cas. Une personne souhaite transférer automatiquement ses messages vers une adresse externe et découvre que la politique de sécurité l’interdit.
C’est généralement à cet instant qu’apparaît la fameuse phrase :
« Mais je pensais que c’était possible. »
Cette phrase, anodine en apparence, révèle souvent un défaut de gouvernance.
La DSI connaissait peut-être parfaitement la règle. Les équipes de sécurité également. Mais le bénéficiaire du service n’en avait pas nécessairement connaissance ou n’en avait pas compris les conséquences.
Une convention de service permet de déplacer cette discussion. Au lieu d’expliquer la règle lorsqu’un problème survient, elle permet de la définir avant que le service soit consommé.
Ce qui n’était qu’une contrainte technique devient alors une condition connue du service.
Dire ce que l’on fournit, mais aussi ce que l’on ne fournit pas
C’est probablement l’un des aspects les plus importants d’une convention mature.
Les DSI sont naturellement habituées à présenter leurs services sous l’angle des fonctionnalités disponibles. Il est plus difficile, mais souvent beaucoup plus utile, d’en expliquer les limites.
Un service n’a pas besoin de tout permettre pour être un bon service.
Il doit en revanche être parfaitement clair sur ce qu’il autorise et sur ce qu’il n’autorise pas.
Si certaines informations ne doivent pas être stockées dans un service, cela doit être dit. Si certains équipements ne sont pas supportés, cela doit être expliqué. Si une fonction n’est accessible qu’à certaines populations, cela doit être connu. Si des mécanismes de sécurité peuvent provoquer un refus d’accès dans certaines circonstances, ce comportement doit faire partie de la description du service.
Une limite clairement annoncée n’est plus nécessairement perçue comme une anomalie. Elle devient une caractéristique connue et assumée. Et cette différence est considérable.
La sécurité ne devrait jamais être une surprise
Les équipes techniques connaissent parfaitement ce phénomène. Une mesure de sécurité est souvent perçue comme raisonnable tant qu’elle reste théorique. Elle devient beaucoup moins populaire lorsqu’elle empêche concrètement quelqu’un de faire ce qu’il souhaitait.
Conditional Access refuse une connexion. Une nouvelle authentification MFA est demandée. Un appareil personnel ne peut plus télécharger un document. Une information classifiée ne peut pas être transférée vers l’extérieur.
La première réaction peut alors être de considérer que « l’informatique bloque ». Pourtant, la sécurité n’est pas un dysfonctionnement du service. Elle en fait partie.
Une convention permet justement de repositionner cette question. Elle explique que certaines conditions d’accès ou certaines limitations sont inhérentes au niveau de sécurité retenu pour le service.
La discussion change alors de nature.
La question n’est plus : « Pourquoi la DSI m’empêche-t-elle de faire cela ? »
Mais plutôt : « Quel niveau de sécurité souhaitons-nous pour ce service et quelles contraintes sommes-nous collectivement prêts à accepter pour l’obtenir ? » Et cette seconde question n’appartient plus uniquement à la DSI. Elle relève pleinement de la gouvernance de l’organisation.
La sécurité devient une responsabilité partagée
C’est sans doute l’un des principaux bénéfices d’une convention de service : elle permet de sortir d’une vision dans laquelle la DSI serait seule responsable de tout ce qui touche au numérique.
Prenons l’exemple d’un espace collaboratif.
La DSI peut être responsable de la configuration technique de la plateforme, de la protection des identités, des politiques d’accès et du maintien du service. Mais faut-il pour autant considérer que la DSI est responsable de la décision d’inviter un partenaire dans un espace contenant des informations métier ?
Probablement pas.
La légitimité de cet accès appartient souvent au métier.
De la même manière, une DSI peut sécuriser une boîte aux lettres et déployer des technologies sophistiquées contre le phishing. Cela ne dispense pas l’utilisateur de rester vigilant lorsqu’un message lui demande dans l’urgence de modifier des coordonnées bancaires. Le numérique crée ainsi une chaîne de responsabilités.
La DSI protège la plateforme. La direction définit ou valide certains usages. Le responsable métier décide qui doit avoir accès à certaines informations. L’utilisateur respecte les règles et signale les situations suspectes. La convention rend cette chaîne visible.
Et ce faisant, elle transforme peu à peu la cybersécurité en une responsabilité collective plutôt qu’en une préoccupation exclusivement technique.
Donner aux directions les moyens de décider
Il existe une autre vertu de la convention de service, peut-être plus stratégique encore. Elle permet de ramener certaines décisions au bon endroit.
Faut-il autoriser un service depuis n’importe quel pays ? Les terminaux personnels sont-ils acceptables ? Certaines données peuvent-elles être partagées avec un partenaire ? Un utilisateur doit-il pouvoir inviter lui-même des personnes extérieures ? Quelle durée de conservation souhaitons-nous appliquer ? Quel niveau de disponibilité attendons-nous réellement ?
Ces questions ont presque toujours une dimension technique.
Mais elles ne sont pas uniquement techniques. Elles concernent également le risque, le métier, les obligations de l’organisation et parfois son image.
La DSI peut expliquer les conséquences d’un choix. Le RSSI peut en analyser les risques. Le DPO ou les fonctions juridiques peuvent apporter leurs propres exigences. Mais certaines décisions appartiennent finalement à la gouvernance.
La convention crée justement un espace dans lequel ces décisions peuvent être explicitées et assumées.
Elle évite qu’un paramètre technique configuré plusieurs années auparavant ne devienne, presque par accident, la politique officielle de l’organisation.
Une formidable protection contre les malentendus
Une convention protège évidemment le bénéficiaire puisqu’elle lui permet de connaître précisément le service auquel il peut prétendre. Mais elle protège également la DSI.
Sans document de référence, les attentes se construisent progressivement, souvent sans que personne ne les ait réellement validées.
« Nous pensions que tout était sauvegardé. »
« Nous pensions pouvoir nous connecter depuis n’importe quel pays. »
« Nous pensions que les équipements personnels étaient supportés. »
« Nous pensions que les documents resteraient accessibles indéfiniment. »
La répétition du mot « pensions » traduit exactement le problème.
Lorsque les règles sont implicites, chacun finit par construire sa propre version du service.
La convention remplace les suppositions par des engagements explicites.
Elle ne permet pas de prévoir toutes les situations, et ce n’est d’ailleurs pas son objectif. Elle permet simplement d’établir un socle commun sur lequel la DSI et les directions pourront s’appuyer lorsqu’une question se présentera.
Un support plus simple et une exploitation plus mature
L’intérêt est également très concret pour les équipes de support.
Lorsqu’un service possède un fonctionnement nominal clairement décrit, il devient plus facile de déterminer si une situation constitue réellement un incident. Une fonctionnalité indisponible peut être une anomalie. Mais elle peut également être volontairement désactivée parce qu’elle ne fait pas partie du service. Un accès refusé peut être un problème d’authentification. Il peut également s’agir de l’application parfaitement normale d’une politique de sécurité. Une convention claire réduit cette ambiguïté.
Elle permet aussi de préciser comment contacter le support, quelles informations doivent accompagner une demande, comment sont traités les incidents majeurs ou encore quelles situations relèvent d’une demande d’évolution plutôt que d’un incident. Ce qui peut sembler, au départ, être un simple travail documentaire participe donc directement à la maturité opérationnelle de la DSI.
Une convention n’est pas un SLA
Il existe parfois une confusion entre convention de service et SLA. Les deux peuvent parfaitement cohabiter, mais ils ne portent pas exactement la même ambition.
Le catalogue de services explique ce que la DSI met à disposition. Le SLA formalise des niveaux de service mesurables lorsque cela est pertinent. La documentation technique décrit l’architecture et les procédures d’exploitation expliquent comment agir.
La convention, elle, occupe un espace intermédiaire particulièrement intéressant.
Elle raconte le service dans un langage compréhensible par la direction bénéficiaire. Elle en décrit l’objet, les fonctionnalités essentielles, les conditions d’accès, les règles de sécurité, les responsabilités, le support et les limites. Elle ne devrait donc pas devenir une documentation d’exploitation déguisée.
Une direction n’a généralement pas besoin de connaître le nom exact d’une politique Conditional Access ou la commande PowerShell utilisée pour créer une boîte aux lettres. Elle doit en revanche savoir que l’accès à certaines informations peut nécessiter un terminal répondant aux exigences de sécurité de l’organisation. Cette nuance est fondamentale.
Le danger du document de 80 pages
Formaliser ne signifie pas compliquer. C’est probablement l’un des pièges les plus importants. Une convention de service qui tente d’expliquer chaque paramètre technique finit rapidement par devenir illisible. Elle sera validée une fois, rangée quelque part et progressivement oubliée.
Le défi consiste au contraire à être précis tout en restant intelligible.
La direction doit pouvoir comprendre rapidement la finalité du service, les populations concernées, ses fonctionnalités principales, les conditions d’accès, les engagements de la DSI et les responsabilités qui lui reviennent.
Les informations techniques détaillées doivent rester dans les référentiels d’exploitation et d’architecture. La convention doit rester un document de gouvernance. Et pour être un bon document de gouvernance, elle doit avant tout être lue et comprise.
Microsoft 365 rend cette démarche presque indispensable
Les plateformes Cloud illustrent particulièrement bien cette nécessité. Un service Exchange Online implique l’identité, la sécurité, la protection contre le phishing, les équipements mobiles, les politiques de conservation et parfois les contraintes géographiques.
Microsoft Teams ajoute la question des invités, des réunions externes, des enregistrements, des transcriptions, de Copilot ou encore des applications et bots tiers.
SharePoint Online et OneDrive posent à leur tour les questions du partage, des propriétaires, des documents sensibles et de la durée de vie des espaces.
Il devient alors pratiquement impossible de continuer à considérer ces environnements uniquement comme des « outils ». Ce sont des services numériques complets. Et tout service important mérite que ses conditions d’utilisation soient comprises.
De fournisseur informatique à fournisseur de services
Cette démarche accompagne aussi une évolution beaucoup plus profonde de la DSI. Une DSI mature n’est plus uniquement l’équipe que l’on appelle lorsqu’un ordinateur ne fonctionne pas ou lorsqu’une application devient indisponible.u Elle conçoit, assemble et opère des services numériques indispensables au fonctionnement de l’organisation. La convention de service matérialise cette évolution.
La conversation avec les directions peut alors dépasser la question traditionnelle :
« Est-ce que cela fonctionne ? »
pour aborder des sujets beaucoup plus structurants :
« Quel service souhaitons-nous réellement fournir ? »
« À quelles populations ? »
« Avec quel niveau de sécurité ? »
« Quelles responsabilités acceptons-nous collectivement ? »
« Et quels risques sommes-nous prêts à assumer ? »
À cet instant, la DSI cesse d’être uniquement un opérateur technique.
Elle devient pleinement un partenaire de la gouvernance de l’organisation.
La convention comme contrat de confiance
Le véritable intérêt d’une convention de service n’est donc pas juridique ou administratif. Il est relationnel. Une bonne convention permet à la DSI de dire à une direction :
« Voici le service que nous nous engageons à vous fournir. Voici ce que vous pouvez en attendre. Voici comment nous le protégeons. Voici également ses limites. De votre côté, voici les responsabilités qui vous reviennent. Et si quelque chose ne fonctionne pas comme prévu, voici comment nous agirons ensemble. »
Il est difficile d’imaginer expression plus simple d’une relation de confiance. La convention n’est donc pas un moyen pour la DSI de se déresponsabiliser. C’est exactement l’inverse.
Elle permet à chacun d’assumer explicitement sa part de responsabilité.
