Les SLA sont des promesses faites aux clients - les OLA garantissent que vos équipes internes peuvent les tenir. Avec Trupeer, vous pouvez gagner des heures sur la rédaction des OLA en partant d’un modèle d’accord de niveau opérationnel gratuit, en le personnalisant avec vos directives de marque, puis en transformant l’OLA en une visite guidée vidéo qui aligne toutes les équipes internes sur des standards de service partagés.

Qu’est-ce qu’un modèle d’accord de niveau opérationnel ?

Un accord de niveau opérationnel, ou OLA, est un accord interne entre des équipes d’une même organisation qui sous-tend un engagement pris envers quelqu’un à l’extérieur. Le service desk promet à l’entreprise une résolution en quatre heures sur les incidents majeurs. Cette promesse ne tient que si l’équipe réseau, l’équipe applicatifs et toute autre équipe de la chaîne jouent leur rôle dans un délai connu.

L’OLA est l’endroit où ces éléments internes sont consignés. Ce n’est pas un contrat : personne ne paie personne, et l’application est entièrement managériale. C’est à la fois sa faiblesse et la raison pour laquelle il peut être honnête d’une manière qu’un contrat ne peut pas.

Un modèle d’accord de niveau opérationnel est la structure réutilisable : les parties, les services couverts, les engagements, les mesures et les modalités de revue. Les modèles de ce type sont faciles à trouver. La plupart vous permettront de rédiger une OLA entièrement conforme… tout en échouant, ce qui est précisément le sujet du reste de cette page.

OLA vs SLA : à quoi chacun s’engage réellement

Trois documents appartiennent à cette famille, et les mélanger crée de vrais problèmes.

Un accord de niveau de service est l’engagement envers le client ou l’entreprise. Il est rédigé dans les termes du client, généralement de bout en bout, et c’est ce qui est reporté à des personnes en dehors de la chaîne de livraison.

Un accord de niveau opérationnel est interne, entre des équipes qui dépendent toutes de la même organisation. Il existe uniquement pour rendre la SLA réalisable et il ne devrait jamais contenir un engagement dont la SLA n’a pas besoin.

Un contrat de soutien est l’accord commercial avec un tiers, un fournisseur ou un prestataire externalisé, qui soutient la même chaîne. Il a une force juridique, contrairement à l’OLA, et il offre généralement le moins de flexibilité des trois : il doit donc être convenu avant la SLA plutôt qu’après.

La conséquence pratique est une règle d’enchaînement. Convenez d’abord des contrats de soutien, puis de la SLA en fonction de ce que ces contrats autorisent, puis des OLA qui complètent le reste. Les organisations qui procèdent dans l’autre ordre promettent régulièrement à l’entreprise quelque chose qu’aucun fournisseur n’a accepté de livrer.

Comment personnaliser ce modèle dans Trupeer

Étape 1 : Ouvrir la section Modèles

Accédez à la section Modèles depuis la navigation principale.

Étape 2 : Sélectionner et ouvrir un modèle

Cliquez sur n’importe quel modèle avec lequel vous souhaitez travailler pour l’ouvrir.

Étape 3 : Développer l’affichage du modèle

Si nécessaire, développez l’affichage du modèle pour voir clairement la mise en page complète et les détails.

Étape 4 : Modifier le modèle

Cliquez sur Modifier pour commencer à apporter des changements au modèle sélectionné.

Dans l’éditeur, vous pouvez :

• Ajouter de nouvelles sections

• Définir ou mettre à jour des règles de mise en forme

• Ajouter un logo et ajuster sa position ainsi que les paramètres associés

Étape 5 : Enregistrer votre modèle personnalisé

Après avoir effectué tous les changements nécessaires, cliquez sur Enregistrer pour stocker le modèle mis à jour comme le vôtre.

Étape 6 : Aperçu et ajustements fins du modèle

Lorsque vous souhaitez voir à quoi ressemble votre modèle personnalisé, ouvrez l’Aperçu.

Depuis l’écran d’aperçu, vous pouvez continuer à effectuer des ajustements directement si nécessaire, afin de garantir que le modèle s’affiche exactement comme vous le souhaitez.

Avec un modèle d’accord de niveau opérationnel, vous pouvez :

• Gagner du temps sur la rédaction : évitez la page blanche grâce à une structure conçue pour les OLA.

• Aligner les équipes internes : des champs intégrés garantissent que chaque équipe connaît ses responsabilités.

• Rester conforme à votre charte : appliquez votre logo, vos polices et vos couleurs à l’aide du kit de marque Trupeer.

• Protéger les SLA clients : des OLA solides empêchent que les transferts internes ne brisent des promesses externes.

• Standardiser entre les services : utilisez le même modèle d’OLA pour chaque accord interne.

• Atteindre des équipes à l’échelle mondiale : traduisez les OLA en 65+ langues en un clic.

Pourquoi chaque équipe atteint son OLA et la SLA échoue encore

C’est le schéma le plus courant en gestion des services, et il ressemble à une contradiction.

Chaque équipe remonte du vert. Le réseau répond dans son heure. Les applicatifs résolvent dans leurs deux heures. Le service desk trie dans les trente minutes. Le rapport mensuel de conformité aux OLA est agréable à lire. Et pourtant, la SLA client échoue sur un tiers des incidents majeurs.

L’explication est que les OLA mesurent le temps à l’intérieur des équipes, tandis que la SLA mesure le temps de bout en bout. La différence entre ces deux chiffres correspond au transit : le ticket qui attend dans une file après réassignation, qui attend d’être pris en charge, ou qui est renvoyé pour obtenir davantage d’informations.

Ce temps n’appartient à personne. Il n’est dans aucune OLA, il n’est reporté nulle part, et il est fréquemment plus important que l’ensemble du temps de travail cumulé.

Ce qui signifie que l’échec est structurel plutôt qu’un problème de performance. Ajouter de la pression aux équipes pour atteindre leurs chiffres actuels ne servira à rien, car elles les atteignent déjà.

L’OLA régit le transfert, pas le travail

Le recadrage qui corrige cela est simple, et il change l’objectif du document.

Une OLA rédigée de la manière habituelle engage une équipe sur la durée de son propre travail. C’est la partie que l’équipe contrôle, donc c’est la partie qu’elle est prête à signer, et c’est aussi la moins utile à convenir, car ce n’était jamais la variable.

Une OLA rédigée correctement engage les équipes sur l’interface entre elles. Ce qui doit être présent dans un ticket avant qu’il soit transmis. Le temps dont dispose l’équipe destinataire pour le prendre en charge. Ce qui se passe lorsque le ticket est incomplet. Qui est responsable du ticket pendant l’intervalle.

Une fois que le transfert devient le sujet, les deux champs manquants deviennent évidents. Les critères d’entrée, c’est-à-dire ce qui doit être vrai avant que l’horloge de l’équipe destinataire ne démarre. Et une allocation explicite du temps de transit lui-même, afin que l’écart entre les équipes corresponde au chiffre de quelqu’un plutôt qu’à celui de personne.

Le reste de tout modèle d’OLA relève de l’administration. Ces deux éléments sont le document.

Critères d’entrée : ce qui doit être vrai avant que l’horloge ne démarre

Le comportement le plus destructeur dans une chaîne multi-équipes est le renvoi : un ticket arrive sans suffisamment d’informations, l’équipe destinataire le renvoie, et son horloge se réinitialise.

Le renvoi est entièrement rationnel du point de vue de l’équipe destinataire. Elle ne peut pas travailler sur le ticket et sa conformité est mesurée sur son propre temps de résolution : le renvoyer protège donc les deux parties. C’est aussi là qu’une grande part du temps écoulé se perd, et c’est invisible dans tous les rapports qui mesurent les équipes séparément.

Les critères d’entrée corrigent cela en déplaçant l’obligation en amont. Chaque ligne d’OLA liste les champs spécifiques qui doivent être renseignés pour que cette équipe accepte le travail. Pour un transfert réseau, il peut s’agir du nom de l’appareil, du code du site, du texte exact de l’erreur, de l’heure à laquelle le problème a été observé pour la première fois et de savoir si d’autres utilisateurs sont impactés. Pour un transfert applicatifs, il peut s’agir de l’utilisateur, de la référence de transaction, des étapes pour reproduire et d’une capture d’écran.

Ensuite, l’engagement de l’équipe expéditrice change de formulation. Pas « triage dans les trente minutes », mais « transmettre un ticket répondant aux critères d’entrée dans les trente minutes ». Même horloge, obligation différente : l’incitation se trouve désormais du côté de l’équipe qui peut réellement rassembler les informations.

L’équipe destinataire conserve le droit de refuser, et ce droit doit être limité : le refus n’est valable que lorsqu’un critère d’entrée nommé est réellement manquant, et chaque refus est consigné avec la raison. La consignation transforme le renvoi, jusque-là habitude invisible, en un chiffre que quelqu’un doit expliquer.

Modèle d’OLA opérationnelle gratuit : la structure à copier

Copiez depuis ici. Les champs marqués d’un astérisque sont ceux que les modèles standard omettent.

En-tête. Référence et version de l’OLA. Parties, c’est-à-dire les deux équipes par leur nom. La SLA ou le service que cela prend en charge. Date d’effet, date de revue et responsable nommé de chaque côté.

Périmètre. Quels services, systèmes ou types de demandes cela couvre, et ce que cela ne couvre explicitement pas.

Heures de service. Couverture pour chaque partie, y compris les dispositions hors heures et la façon dont elles diffèrent. Des horaires non alignés entre deux équipes de la même chaîne constituent un écart courant et silencieusement fatal.

Tableau des engagements. Une ligne par type de demande ou par priorité, avec : le déclencheur, les critères d’entrée, le temps de réponse, le temps de résolution ou de renvoi, le temps de transit alloué et le point d’escalade.

Escalade. Qui est contacté à chaque étape, par quel canal, et après combien de temps. Incluez le parcours hors heures.

Dépendances. Ce dont cette équipe a besoin des autres, y compris tout contrat de soutien avec un tiers, avec ses propres délais indiqués afin que les calculs puissent être vérifiés.

Mesure. Ce qui est mesuré, depuis quel système, par qui, et à quelle fréquence c’est reporté. Incluez le taux de renvoi en plus du temps de réponse et de résolution, car c’est la métrique qui révèle si les critères d’entrée fonctionnent.

Exceptions. Circonstances convenues où les engagements ne s’appliquent pas, par exemple pendant un incident majeur déclaré ou lors d’une période de gel des changements.

Revue. Dates, et ce qui déclenche une revue hors cycle.

Copiez jusqu’ici. Limitez-vous à deux ou trois pages. Une OLA suffisamment longue pour nécessiter une double lecture ne sera pas consultée pendant un incident, et c’est précisément pendant un incident que cela compte.

Comment vérifier que les OLA s’additionnent réellement à la SLA

Avant de signer quoi que ce soit, faites les calculs. Cela prend quinze minutes et c’est presque systématiquement ignoré, car les OLA sont négociées une par une avec des équipes différentes, à des jours différents.

Deux règles rendent cela utile. Le temps de transit doit apparaître comme une ligne à part, car c’est l’objectif même. Et chaque chaîne a besoin d’une marge, car une chaîne qui s’additionne exactement à la SLA échoue dès que quelque chose se passe légèrement de travers. Dix à quinze pour cent constituent une marge raisonnable.

Si la somme dépasse la SLA, vous avez trois options honnêtes : renégocier la SLA, réduire le temps d’une équipe avec quelque chose qui rend cela possible, ou supprimer un transfert. Ce que vous ne pouvez pas faire, c’est signer des OLA qui garantissent un échec, puis gérer la performance en fonction de ces engagements : c’est la position dans laquelle se trouvent un nombre surprenant de service desks.

Le retailer dont le temps de transit était plus long que son travail

Rendlesham Group gère plusieurs marques retail avec environ six mille employés et un service desk IT interne qui prend en charge les magasins et le siège.

Sa SLA d’incident P2 envers l’entreprise prévoyait quatre heures jusqu’à la résolution. Le taux de non-conformité sur P2 était resté autour de trente-huit pour cent pendant deux ans. La conformité OLA de chaque équipe était reportée mensuellement et chaque équipe était en vert.

Quelqu’un a finalement horodaté chaque changement d’état sur cent vingt incidents P2 en échec.

Le temps total médian écoulé était de six heures cinquante et une minutes. Sur ce total, trois heures douze minutes correspondaient au temps passé au sein d’une équipe en train de traiter activement le ticket. Trois heures trente-neuf minutes correspondaient au transit : le ticket attendait dans une file après réassignation, attendait d’être pris en charge, ou était renvoyé.

Plus de la moitié du temps écoulé sur un incident en échec n’appartenait à personne et n’était reporté nulle part.

Le plus gros contributeur était le renvoi. Quarante et un des cent vingt tickets avaient été renvoyés au moins une fois par une équipe destinataire pour informations insuffisantes, et chaque renvoi ajoutait une médiane d’une heure vingt minutes, tout en réinitialisant l’horloge de cette équipe. Les deux raisons les plus courantes étaient l’absence de texte d’erreur ou de capture d’écran, et l’absence de confirmation du magasin impacté par l’incident.

Les changements étaient ciblés. Des critères d’entrée ont été intégrés dans chaque ligne d’OLA. L’engagement du service desk a été réécrit : de « triage dans les trente minutes » à « transmettre un ticket répondant aux critères d’entrée dans les trente minutes ». Quinze minutes de transit ont été allouées par transfert et comptabilisées contre l’équipe destinataire une fois les critères d’entrée remplis. Et chaque renvoi a été consigné avec une raison.

Au cours des deux trimestres suivants, le taux de renvoi est passé de trente-quatre pour cent des P2 à neuf. Le temps de transit médian est passé de trois heures trente-neuf minutes à une heure six. Le taux de non-conformité P2 est passé de trente-huit pour cent à onze.

Le temps de résolution interne de chaque équipe n’a pas changé de manière significative. Personne n’a travaillé plus vite. Le temps qui appartenait à personne a simplement été attribué à quelqu’un.

Comment rédiger une OLA, étape par étape

Commencez par la SLA, pas par un modèle. Notez ce qui a été promis au client, de bout en bout, avec sa définition d’horloge.

Cartographiez la chaîne. Chaque équipe qui touche une demande de ce type, dans l’ordre, y compris tout tiers. Dessinez les transferts comme des étapes distinctes plutôt que comme des flèches.

Pour chaque transfert, posez une question à l’équipe destinataire : de quoi avez-vous besoin dans le ticket pour démarrer le travail sans qu’on vous le renvoie. La réponse, une fois notée, devient vos critères d’entrée. Les équipes répondent facilement et précisément, et la plupart n’ont jamais été interrogées.

Ensuite, convenez des délais en respectant les calculs ci-dessus, plutôt que équipe par équipe. Le faire en une seule discussion avec tout le monde prend une heure et évite entièrement le problème de somme.

Allouez explicitement le temps de transit et décidez qui en est responsable. Quinze minutes par transfert constituent un bon point de départ et cela doit être compté contre l’équipe destinataire.

Concluez aussi sur la mesure, y compris le taux de renvoi, et d’où elle provient. Si vos outils ne peuvent pas le produire, autant le savoir avant de signer plutôt qu’au premier cycle de revue.

Puis testez sur un trimestre avant de formaliser. Les premières versions sont généralement incorrectes à un ou deux endroits, et il est plus facile de les corriger avant qu’il n’y ait des signatures.

Erreurs courantes d’OLA et ce que chacune coûte

Mesurer les équipes et non la chaîne. Tout le monde est en vert et la SLA échoue. C’est l’échec le plus courant et le sujet de cette page.

Pas de critères d’entrée. Le renvoi devient la défense rationnelle de l’équipe destinataire, et le temps écoulé gonfle de façon invisible.

Des temps qui ne s’additionnent pas. L’ensemble des OLA garantit un échec et personne ne l’a jamais additionné.

Heures de service non alignées. Une équipe couvre jusqu’à six heures, la suivante jusqu’à cinq. Tout ce qui arrive après cinq heures reste en attente jusqu’au lendemain, ce que aucun rapport ne montre, car les deux équipes sont dans leurs horaires.

Copier le langage des SLA dans une OLA. Les pénalités, les crédits et la formulation juridique n’ont pas leur place ici, et les importer pousse les équipes à négocier sur la défensive au lieu de négocier honnêtement.

Rédiger une OLA avec un tiers. Si de l’argent change de mains, il s’agit d’un contrat de soutien et cela nécessite l’implication des achats et du juridique, pas un modèle. Notre modèle de politique d’achats IT couvre le parcours d’approbation.

Signer et classer. Une OLA que personne ne relit décrit une chaîne de service qui n’existe plus, en général, au bout d’environ un an.

Comment gérer et relire les OLA une fois qu’elles existent

Reportez la chaîne, pas les composants. Un seul chiffre compte : la performance de bout en bout par rapport à la SLA. Les métriques d’OLA existent pour l’expliquer, plutôt que pour rester seules.

Relisez trimestriellement, avec toutes les parties réunies. Les revues bilatérales reproduisent le problème initial, car les écarts se situent entre les parties qui ne sont jamais dans la même conversation.

Surveillez trois éléments. Le taux de renvoi par transfert, qui vous indique où les critères d’entrée doivent être améliorés. Le temps de transit par transfert, qui vous indique où les files se forment. Et la proportion d’incidents qui suivent un parcours que l’OLA ne décrit pas : cela vous montre que le document s’est éloigné de la réalité.

Déclenchez une revue hors cycle lorsqu’une équipe se réorganise, lorsqu’un système passe d’une équipe à une autre, lorsqu’un nouveau tiers entre dans la chaîne, ou lorsque la SLA sous-jacente change. Ces quatre situations arrivent plus souvent que ce que suppose le cycle annuel de revue.

OLA, SLA ou contrat de soutien : de quoi avez-vous besoin ?

Si l’engagement concerne quelqu’un en dehors de votre organisation de livraison, qu’il s’agisse d’un client externe ou d’une unité métier interne servie, c’est une SLA.

Si l’engagement concerne deux équipes à l’intérieur de la même organisation, sans qu’aucune somme d’argent ne change de mains, c’est une OLA.

Si l’engagement concerne un fournisseur dans le cadre d’un arrangement commercial, c’est un contrat de soutien et il faut l’implication du juridique et des achats, plutôt que ce modèle.

Le cas délicat est celui du centre de services partagés ou d’une équipe interne avec un modèle de refacturation, qui se situe entre une OLA et une SLA. La réponse pratique consiste à le rédiger comme une OLA et à supprimer tout langage sur les pénalités, car les dispositifs de pénalités internes produisent de manière fiable des comportements défensifs et, pire encore, un service de moindre qualité.

Pour les définitions orientées client et les formulations de réponse qui se trouvent au-dessus de tout cela, notre modèle de réponse du service desk et notre modèle de ticket et de résolution couvrent la couche que l’utilisateur final voit réellement.

Puis-je obtenir un modèle d’OLA en Word ou Excel ?

Word pour l’accord, car le périmètre, les exceptions et les sections de revue sont rédigés en texte, et le document est diffusé pour validation.

Excel pour deux parties spécifiquement. Le tableau des engagements, où vous souhaitez les critères d’entrée, les délais et l’allocation du transit dans des colonnes que vous pouvez trier et vérifier. Et la feuille de calcul, où chaque chaîne s’additionne à sa SLA et signale tout ce qui manque de marge. Cette deuxième feuille est celle qu’il vaut mieux construire en premier, car elle modifie souvent ce que vous étiez sur le point de convenir.

PDF pour la version signée, exportée depuis la source. Conservez la version de travail modifiable, car les critères d’entrée devront être ajustés après le premier trimestre de renvois réels.

Comment garder l’OLA et la réalité synchronisées

Une OLA décrit une chaîne de travail qui change constamment. Les équipes se réorganisent, les systèmes bougent, les outils changent, et le document est la dernière chose que quelqu’un met à jour.

La partie qui devient obsolète le plus vite, ce sont les critères d’entrée, car ils décrivent ce qu’un ticket doit contenir, et ce qu’un ticket doit contenir dépend de la façon dont les outils actuels et le processus actuel fonctionnent réellement.

Trupeer AI aide en rendant les procédures sous-jacentes peu coûteuses à maintenir à jour. Enregistrez une fois le processus de triage ou de transfert, et vous obtenez une procédure écrite avec les étapes et les écrans capturés, que le service desk peut suivre et qui montre clairement quelles informations sont collectées. Lorsque les outils changent, enregistrez à nouveau plutôt que de réécrire.

Enregistrez-le. Mettez-le à votre marque. Traduisez-le. Trupeerisez-le.

Le créateur de SOP couvre les procédures dont l’OLA dépend, et notre modèle de SOP IT explique comment décider lesquelles valent la peine d’être maintenues. La documentation conserve les accords et les procédures ensemble, et les instructions de configuration se trouvent dans le guide de configuration du modèle de document.

Questions fréquentes

Existe-t-il un modèle d’accord de niveau opérationnel gratuit en Word ?

La structure ci-dessus se colle directement dans Word ou Google Docs, y compris les champs de critères d’entrée et d’allocation du transit que les modèles standard omettent. Il n’y a pas de téléchargement verrouillé et pas de formulaire. Conservez le tableau des engagements dans un tableur et faites-y référence, car cette partie doit être triée et additionnée.

Existe-t-il un modèle d’accord de niveau opérationnel gratuit en PDF ?

Exportez la version signée en PDF une fois que les parties l’ont approuvée, et conservez la copie de travail modifiable. Les critères d’entrée nécessitent presque toujours des ajustements après le premier trimestre, une fois que vous pouvez voir pour quels tickets ils sont réellement renvoyés.

Existe-t-il un modèle d’accord de niveau opérationnel gratuit en Excel ?

Excel est le bon endroit pour le tableau des engagements et pour la vérification des calculs. Une feuille avec une ligne par transfert et un total cumulé par rapport à la SLA, qui signale toute chaîne avec moins de dix pour cent de marge. Construire cette feuille avant de négocier a tendance à modifier ce qui est négocié.

Où puis-je trouver un exemple d’OLA en PDF ?

Plusieurs fournisseurs ITSM et organismes publics publient des modèles d’OLA et de SLA sous forme de documents, et ils sont raisonnables en termes de structure. Lisez-les pour les sections plutôt que pour le contenu, car les engagements dans n’importe quel exemple publié sont la chaîne de quelqu’un d’autre, et les délais n’ont pas de sens en dehors de la SLA qu’ils étaient censés soutenir.

Qui signe un accord de niveau opérationnel ?

Le responsable nommé de chaque côté, qui devrait être le manager responsable de la livraison de l’équipe plutôt qu’une fonction de gestion des services. Une OLA signée uniquement par la gestion des services est un souhait, car la personne qui doit lui allouer des ressources n’était pas dans la salle.

De combien d’OLA un service desk a-t-il besoin ?

Moins que ce que la plupart des équipes imaginent. Une par paire d’équipes qui échange régulièrement du travail, couvrant tous les types de demandes dans un seul tableau d’engagements, plutôt qu’une par service. Au-delà d’environ une douzaine, la maintenance devient la contrainte et les documents deviennent obsolètes plus vite qu’ils ne sont relus.

Un accord de niveau opérationnel doit-il inclure des pénalités ?

Non. Il n’existe pas de relation juridique à faire respecter et les dispositifs de pénalités internes produisent de manière fiable des comportements défensifs : les équipes rejettent le travail, débattent du moment où l’horloge démarre et optimisent leur propre chiffre plutôt que le résultat. Reportez plutôt la chaîne de bout en bout : cela rend la conséquence partagée visible sans que personne ne soit sanctionné.

À quelle fréquence les OLA doivent-elles être revues ?

Trimestriellement avec toutes les parties présentes, plus une revue hors cycle dès qu’une équipe se réorganise, qu’un système passe d’une équipe à une autre, qu’un tiers entre dans la chaîne, ou que la SLA sous-jacente change. Le rythme trimestriel détecte les dérives et les déclencheurs détectent les changements qui rendent le document incorrect du jour au lendemain.