Je vous l’accorde, créer un contrat incluant un SLA n’est pas forcément une mince affaire, au moins en théorie. Il faut définir des indicateurs métiers pertinents et représentatifs. Il faut savoir s’engager à la réussite de ses clients. Il faut créer un contrat souple et capable de s’adapter. Il faut valider des logiciels et des solutions tiers. Il faut gérer des risques et surtout créer un environnement gagnant/gagnant.

C’est vrai en théorie au moins. En pratique, le SLA est souvent un bon moyen pour quelques uns de se faire de l’argent facilement. A qui la faute ? Au premier rang des accusés, la complexité liée à la mise en oeuvre d’un système de mesures en phase avec l’entreprise. Détourner les systèmes de mesure devient alors un « sport national » et l’objet de comportements déviants. J’ai en mémoire des collègues s’appelant entre-eux pour tenir leur objectif de nombre d’appels par jour. Mais si les systèmes de mesure sont suspects, c’est ce qu’on réclame au nom de l’engagement qui pourri probablement, encore plus, ce type de contrats. Ce n’est pas perdu pour tout le monde et certains peuvent alors se faire de l’argent facilement. Cet article explore 10 de ces « mauvaises » pratiques que j’ai rencontrée. Dans ce domaine, vous en avez surement également vue de toutes les couleurs alors n’hésitez pas à commenter cet article avec vos idées ou vos expériences.

#1. Engagez vos clients dans la durée. Quitte à se faire de l’argent, autant que ça dure longtemps et que vos clients ne puissent pas s’en sortir sans y laisser leur chemise. En contrepartie d’un coût journalier très faible, n’hésitez pas à engager vos clients sur 5 ans ou à les faire payer des indemnités disproportionnées.

#2. Plafonnez les pénalités globale à un pourcentage du montant du contrat. Dans l’idéal, choisissez 20% ; en effet, avec un objectif de marge de 30%, si vous arrivez malgré tout à perdre de l’argent, c’est que ce métier n’est pas pour vous.

#3. Facturez au temps passé et s’engager sur les moyens. Le pire que j’ai vu dans ce domaine est probablement la facturation à la minute mais quelque soit le système, vous serez toujours gagnant. Imaginez en effet que quand vous faites une erreur, le client vous paiera le temps que vous passerez à corriger vos erreurs. Sans aller jusque là, moins efficace vous êtes, et moins vous avez de compétences techniques, plus vos factures sont élevées. Plus vous avez de moyens et plus vous facturerez. C’est toujours agréable de ne pas à se soucier d’améliorer la qualité de son travail !

#4. Limitez vos engagements à votre seule responsabilité. C’est bien connu, les absents ont toujours tord. Ne pas couvrir le risque des autres (par exemple, ne pas couvrir les impacts des bugs Oracle), vous permettra de toujours vous en sortir en rejetant la faute sur d’autres.

#5. Créez un processus d’arbitrage négocié. Vous ne pouvez pas imaginer tous les cas, si ? Pour les cas non prévus, mettez en place un processus négocié. Si en outre vous empêchez votre client de faire appel à la concurrence, vous aurez tout loisir de mener toutes les négociations en mettant votre client à genou. Dans l’idéal, s’il y a un jugement à effectuer, il faudrait que ce soit à vous de le faire ! Et puis de toute façon, il n’est pas possible de tout prévoir alors qu’un processus négocié, c’est facile à créer. Dans ce cadre, si vous pouviez ne pas prévoir le temps associé au passage d’un patch, au clonage d’un environnement, etc… C’est vrai après tout, ça dépend du patch…

#6. Ne prenez pas d’engagement sur la qualité et le temps des indisponibilités planifiées. C’est vrai. Pourquoi être performant dans les opérations de maintenance ? Après tout ce n’est pas vous qui demandez à effectuer ces opérations de maintenance.

#7. Multipliez les seuils, les périmètres et les niveaux. La « fragmentation » du SLA vous permet de réduire le niveaux des pénalités. Diviser pour régner ! Statistiquement, vous réduisez le risque découpant vos systèmes en petit morceaux. Un bon exemple est de prendre un engagement de service mensuel… Comme ça si vous n’atteignez pas vos objectifs sur un mois, vous en avez 11 pour vous refaire. Si vous découpez votre SI par composants, la probabilité que vous cassiez en même temps vos serveurs d’applications et vos bases de données est très faible.

#8. Définissez des seuils bas pour les seuils hauts. Restez flou. 3 heures d’indisponibilité non planifiées par mois pour une base de données est très facile à obtenir avec Oracle et ça parait beaucoup à un directeur financier. Ce n’est qu’une disponibilité 99,6 et ça peut avoir un impact sur l’application bien plus élevé que simplement 3 heures d’indisponibilité, mais qui sait ? Prendre un temps d’intervention de 15 minutes après détection du problème par le système de supervision dans 90% des cas, c’est un super moyen de (1) ne pas être sure de ce qui est détecté, de (2) ne pas dire combien de temps le système de supervision prend pour détecter le problème ou (3) c’est une bonne façon de jouer à la loterie en vous donnant le droit de rater 1 erreur sur 10 ou (4) c’est un bon moyen de dire que vous ne prêterez pas attention au nombre d’incident ou à la gravité des incidents. 

#9. Engagez-vous la disponibilité des composants.C’est vrai (cf #4), vous ne pouvez pas vous engager sur les composants des autres alors les performances d’une application ? En plus, essayez de démontrer que le composants n’était pas disponible, vous… Tant qu’il y a des process qui tournent, c’est sans doute que le système est disponible. Certe un tablespace était plein mais le système était partiellement disponible.

#10. Interdisez tous les accès aux environnements de qualité et de production. C’est vrai, si vous vendez un service, seul le constat de l’atteinte du niveau compte, non ? Pourquoi jouer la transparence ? En plus si votre client accède aux environnements, il risque de casser le système et ce sont vos engagements. Oui, oui, même en lecture seule…

Ne vous trompez pas, même si la grande majorité du service IT est encore fournie aujourd’hui en France sans engagement et sans définition d’un niveau de service, en assistance technique, ce n’est surement pas l’avenir… Ce n’est pas non plus une raison pour mettre en œuvre des pratiques à la limite de l’honnêteté. Veillez à créer un contrat gagnant/gagnant, à aligner les intérêts sur le métier, à créer des primes en plus des pénalités. C’est probablement une des clés de l’évolution des contrats IT. Et vous, quelles mauvaises pratiques des contrats avez-vous rencontrées ?