Alors que le marché numérique français souffre (selon numeum il devrait plafonner à +1,8 % cette année, contre +3,5 % en 2024) les DSI sont sommées par leur direction de démontrer la valeur réelle de chaque euro dépensé, fournisseurs inclus. Dans le même temps, en Europe, la demande pour les services « as-a-service » a encore progressé, signe d’un basculement vers des modèles de sourcing plus flexibles et orientés résultats.
Passer des SLA d’activité aux XLAs et engagements d’outcomes mesurables
Dans un contexte budgétaire plus contraint, on ne plus piloter par les moyens, il faut forcément prouver des résultats visibles par les métiers.
Les SLA ont longtemps structuré les contrats IT autour d’indicateurs d’activité type disponibilité, délais de résolution ou volumes traités. Utile, mais insuffisant dès lors que l’exécutif attend des effets tangibles (adoption des usages, satisfaction employé, temps utile restitué, résilience applicative vécue par l’utilisateur, etc.). D’où l’émergence d’XLAs (Experience Level Agreements) et d’engagements de résultats. L’idée ? On ne rémunère plus seulement la conformité à un processus, on récompense l’expérience et l’impact métier obtenus (ex. satisfaction post-incident, taux de réussite d’un parcours critique ou réduction du temps d’indisponibilité réellement perçu).
Ce mouvement s’observe au rythme du marché. Les DSI renégocient massivement leurs contrats cloud et infogérance à l’occasion des renouvellements, non pas pour ajouter des pages d’indicateurs, mais pour réarticuler la valeur autour de l’expérience et de la performance utile…
…Et surtout, pour professionnaliser la bascule.
Pour passer des SLA aux XLAs et piloter ainsi une relation fournisseurs orientée outcomes, les DSI s’appuient de plus en plus souvent sur des experts externes (exemple d’offre de pilotage des contrats IT) afin de cadrer et mettre en place la démarche de transformation.
En toile de fond, le marché européen des services « XaaS » a enregistré en 2024 une progression à deux chiffres, pendant que les services gérés restaient plus atones. Les acheteurs déplacent donc la valeur vers des modèles pay-per-use/à la performance, là où l’XLA trouve naturellement sa place.
Modèles de pricing : capacity vs. outcome-based, shared risk/reward, gain-share
Une fois l’objectif d’expérience posé, la structure de prix doit cesser d’encourager la consommation de moyens et commencer à récompenser l’impact.
Trois familles dominent ici :
- Capacity-based (temps & moyens, forfaits de capacité, T-shirt sizing). Simple, lisible, mais peu impactant en termes de résultats. À réserver aux chantiers exploratoires ou aux socles mutualisés dont l’objectif est la disponibilité, pas la valeur directe.
- Outcome-based (paiement conditionné à des résultats mesurables). Ici, la rémunération est liée à un indicateur-phare (taux de mise à jour poste à J+7, stabilité d’un tunnel e-commerce, réduction du temps d’attente au support interne ou NPS employé après résolution). Le nœud du contrat n’est plus « combien d’heures ? », mais « quelles preuves ? ».
- Shared risk/reward & gain-share (partage des gains). Idéal lorsque le fournisseur a un vrai levier sur l’optimisation (observabilité, automatisation L2/L3, FinOps, rationalisation des licences). L’idée ici est de définir une ligne de base vérifiée, un mode de calcul des gains (économie récurrente, revenus incrémentaux, baisse des tickets, réduction du MTTR) et une clé de partage progressive pour éviter les effets d’aubaine.
Le point d’attention n’est pas théorique, il faut des métriques vérifiables, un périmètre de responsabilité clair et un calendrier d’observation indépendant (mensuel pour le run, trimestriel pour les gains).
Écosystème partenaires : intégrateur, éditeur, niche experts, comment orchestrer la « constellation »
Bien sûr, une structure tarifaire orientée résultats ne produit rien si la chaîne d’exécution reste morcelée. Le sourcing 3.0 impose donc de penser l’écosystème comme un système, pas comme une addition de prestataires.
Dans la plupart des DSI, le modèle qui s’impose ressemble à une constellation. Un intégrateur pilote le run et les chantiers de transformation, les éditeurs cloud et SaaS fixent le rythme des évolutions, tandis que des experts de niche (FinOps, sécurité, observabilité, data, conduite du changement…) viennent densifier l’ensemble. L’enjeu n’est plus de « tenir » chaque contrat, mais d’obtenir un résultat collectif mesurable avec disponibilité ressentie d’une application critique, adoption d’un poste de travail modernisé, baisse du MTTR sur une chaîne industrielle.
En clair, l’écosystème n’apporte de valeur que s’il fonctionne avec une grammaire commune, des interfaces claires et une responsabilité partagée sur l’outcome, au-delà des silos organisationnels.
Gouvernance conjointe : cockpit commun, backlog partagé, arbitrages trimestriels
Mais cette « constellation » n’avance pas seule et a besoin d’un cockpit et des règles d’arbitrage visibles par tous.
La gouvernance du sourcing 3.0 repose sur trois étages théoriques :
- Un cockpit commun : un jeu de tableaux de bord partagé (DSI, intégrateur, éditeurs, niche experts) qui consolide outcomes, XLAs, coûts unitaires, incidents majeurs, dette technique, perception utilisateur. L’outil importe peu, la source unique de vérité est essentielle.
- Un backlog partagé : au lieu de comités éparpillés, un backlog valeur hiérarchisé : en haut, 3-5 objectifs d’outcome par trimestre avec leurs key results (ex : « disponibilité ressentie à 99,8 % sur l’app mobilité », « NPS support interne +10 pts »).
- Des arbitrages trimestriels : un value review formel décide des réallocations de budget (capacity -> outcome), des bonus/malus sur XLAs, des pivots nécessaires (ex. renforcer l’observabilité plutôt que multiplier les tickets L1).
La dynamique marché plaide globalement pour cette discipline. Quand les revenus des services gérés progressent peu mais que le XaaS grimpe, il faut des rituels qui re-mettent la preuve d’impact au centre et évitent l’empilement de coûts fixes.
Clauses essentielles : réversibilité, propriété des assets, sécurité, évolutivité
Les XLAs fixent le « pourquoi », la gouvernance organise le « comment », reste à sécuriser le « jusqu’où » dans le contrat.
Terminons donc par un petit point sur les clauses essentielles à prévoir :
- Réversibilité & portabilité. Définissez un périmètre réversible (scripts, playbooks, IaC, runbooks, configurations, métadonnées), un format ouvert d’export (données, logs, traces) et un plan de transfert testé à blanc. La montée du XaaS rend la sortie aussi stratégique que l’entrée.
- Propriété des assets & droits d’usage. Clarifiez qui détient quoi : artefacts d’automatisation, modèles d’IA d’exploitation, tableaux de bord, landing zones. S’il y a co-développement, prévoyez la copropriété, le droit de réutilisation et la valorisation en cas de gain-share.
- Sécurité & conformité. Appliquez une clause de sécurité by design avec gestion des secrets, traçabilité, durcissement, revue des dépendances, obligations de patch critique, tests réguliers (pentests, purple teaming). Les obligations de notification d’incident et de co-opération doivent être coordonnées avec les éditeurs SaaS.
- Évolutivité & adaptation. Afin de « laisser vivre » les XLAs, prévoyez également une clause d’ajustement semestriel des indicateurs et de leur cible, en maintenant la comparabilité statistique (définitions, fenêtres de mesure, population observée). Prévoyez aussi des mécanismes anti-périmètre fluide (si la complexité augmente, l’objectif et la rémunération bougent de concert).
- Mécanique financière. Bonus/malus plafonnés, filets de sécurité (cap & floor), earn-back en cas de sous-performance rattrapée. Pour les gain-share, détaillez la méthode de calcul (baseline indépendante, saisonnalité, événements exogènes) et les modalités d’audit.
