Il y a dans le marché de l’advisory sur les services IT un paradoxe qui me frappe depuis des années : les personnes chargées de conseiller les entreprises sur le choix de leurs fournisseurs technologiques sont, dans la grande majorité des cas, des personnes qui n’ont jamais construit, pricé, livré ou défendu un service IT face à un client mécontent.
Ce n’est pas une critique. C’est une observation structurelle. Et elle a des conséquences réelles sur la façon dont les décisions de sourcing sont prises, et sur le nombre de ces décisions qui se révèlent fausses.
Le métier vu de l’intérieur
J’ai passé plus de quinze ans de l’autre côté de la table. Pas comme celui qui évalue les services IT, mais comme celui qui les conçoit, les vend, les livre et en répond quand quelque chose ne marche pas.
Chez YNAP (Yoox pour les plus anciens), j’ai vu comment l’une des plus grandes plateformes e-commerce européennes gérait la relation avec ses fournisseurs technologiques. Pas en théorie : dans la pratique quotidienne des choix d’architecture, des négociations sur les livrables, des décisions qui déterminent si un projet livre de la valeur ou seulement du code.
Comme CTO d’Anthis, j’ai bâti depuis zéro l’infrastructure technique et les processus de livraison d’une entreprise. C’est l’expérience qui apprend que la différence entre un service IT qui marche et un qui non n’est presque jamais dans la techno choisie, mais dans la qualité du processus décisionnel qui mène à cette techno.
Et aujourd’hui, comme Head of Tech & Partner d’Oltrematica (oui, ce rôle n’existe pas formellement, on y reviendra), je gouverne un portefeuille de projets pour des clients allant de TIM à Randstad, de la Région Abruzzes aux Chambres de Commerce. J’écris des RFP et j’y réponds. Je définis des SLA et je dois les respecter. Je price des services managés en sachant exactement combien coûte chaque maillon de la chaîne de livraison.
Cette expérience m’a donné accès à un type de connaissance difficile — peut-être impossible — à acquérir de l’extérieur.
Les choses qu’on voit seulement de l’intérieur
Quand je lis les frameworks d’évaluation des prestataires IT (Magic Quadrant, PEAK Matrix, ISG Provider Lens), je reconnais la qualité de l’analyse et la rigueur méthodologique. Mais je vois aussi les angles morts. Et ce sont toujours les mêmes.
Le coût réel d’un service IT n’est pas dans le prix
Le prix coté dans une offre de services managés est un nombre. Le coût réel est un système complexe qui inclut le prix, plus le coût des inefficacités de communication, plus le coût de la dette technique qui s’accumule quand le prestataire coupe les coins pour rester dans le budget, plus le coût d’opportunité des fonctionnalités non livrées parce que le contrat ne les prévoit pas.
Un analyste qui évalue les prestataires en comparant les tarifs journaliers mesure la mauvaise variable. Un prestataire qui cote 400 € / jour et livre en 20 jours coûte moins qu’un autre qui cote 300 € / jour et y met 40. Mais pour savoir lequel des deux livrera en 20 et lequel en 40, il faut savoir lire l’architecture proposée, la composition de l’équipe, le niveau d’automatisation des processus de livraison.
C’est une compétence qui vient d’avoir bâti ces processus, pas de les avoir observés.
Les SLA sont un langage, pas seulement un contrat
D’expérience, la majorité des problèmes dans les contrats d’outsourcing IT ne naît pas de SLA mauvais. Elle naît de SLA ambigus.
Un SLA qui dit « disponibilité 99,9 % » est techniquement précis mais opérationnellement vide s’il ne précise pas : comment mesure-t-on la disponibilité ? Inclut-on la maintenance programmée ? Quelle fenêtre temporelle pour le calcul ? Que se passe-t-il quand le downtime est causé par un tiers (cloud, CDN, DNS) ?
J’ai écrit des SLA pendant des années. J’ai appris qu’un bon SLA n’est pas celui qui promet le plus, mais celui qui définit avec précision chirurgicale ce qui arrive quand les choses tournent mal. Parce que dans les services IT, les choses tournent toujours mal tôt ou tard. La qualité du prestataire se mesure dans la réponse, pas dans la promesse.
La composition de l’équipe est plus importante que sa taille
Les frameworks d’évaluation tendent à récompenser les prestataires aux grandes équipes et delivery centers multiples. Métrique rassurante pour qui achète : plus de monde = plus de capacité. Mais quiconque a géré des équipes de dev sait que non.
Une équipe de cinq seniors bien coordonnés produit plus d’output de qualité qu’une équipe de quinze avec trois couches de management et rotation continue. Surtout quand cette équipe de cinq utilise des méthodologies AI-native qui multiplient la productivité individuelle.
Chez Oltrematica, nous gérons simultanément 8 à 10 projets actifs avec une équipe d’environ 10 personnes. Pas parce que nous sommes des héros, mais parce que nous avons investi dans l’automatisation, dans des processus de livraison efficaces, dans des outils qui éliminent le travail à faible valeur. C’est l’efficacité qui n’apparaît dans aucun quadrant.
La valeur de la perspective opérationnelle dans l’advisory
Je ne suggère pas que tous les analystes doivent avoir travaillé comme prestataires IT. Je suggère que la perspective opérationnelle est un asset stratégique de l’advisory aujourd’hui dramatiquement sous-représenté.
Quand un CISO me demande si un prestataire de managed security est fiable, je ne dois pas me baser que sur les certifications et les références. Je peux lire l’architecture proposée et savoir si elle a été conçue pour être opérée ou seulement pour gagner l’appel d’offres. Je peux regarder le Statement of Work et repérer les zones grises qui deviendront des litiges contractuels dans 18 mois. Je peux juger si le modèle de staffing proposé est soutenable ou si le prestataire promet une équipe qu’il n’a pas et qu’il devra constituer after-the-fact.
Ce type d’insight ne vient pas de la rigueur analytique. Il vient d’avoir vécu les mêmes dynamiques de l’autre côté. Et il a une valeur énorme pour les clients enterprise sur le point de prendre des décisions de sourcing à plusieurs millions.
La convergence nécessaire
Le marché de l’IT services advisory entre dans une phase où la complexité des décisions de sourcing croît exponentiellement. IA, compliance européenne, reshoring, nouveaux modèles de pricing, cybersecurity by design : autant de dimensions qui exigent une compréhension technique profonde pour être bien évaluées.
Les frameworks génériques ne suffisent plus. Les clients demandent — et ont le droit d’obtenir — des advisors qui parlent la langue des prestataires avec la même aisance que la langue du business.
C’est une convergence que le marché n’a pas encore produite de façon systématique. Mais elle est inévitable. Et qui l’anticipera aura un avantage concurrentiel énorme.
Cet article est le premier d’une série sur ma vision du marché IT services sourcing. Dans le prochain billet, j’explorerai mon parcours personnel — du dev au partner — et comment chaque étape a contribué à construire une perspective intégrée sur le marché des services IT.
Ce qu'il faut retenir
Le prix dans une offre est un nombre ; le coût réel est un système qui inclut inefficacités, dette technique et fonctionnalités non livrées.
Un bon SLA ne promet pas plus, il définit avec précision chirurgicale ce qui arrive quand les choses tournent mal.
Cinq seniors bien coordonnés battent quinze personnes avec trois étages de management : la composition compte plus que la taille.
Avec l’IA, la journée-homme est une unité variable ; comparer des prestataires sur le coût horaire mesure la mauvaise variable.
La compétence opérationnelle est un input pour l’advisory, pas du bruit : aujourd’hui elle est dramatiquement sous-représentée.
Questions & réponses
Quel est l'angle mort structurel de l'advisory IT ?
La plupart des personnes chargées de conseiller les entreprises sur l’achat de technologie n’ont jamais construit, pricé, livré ou défendu un service IT face à un client mécontent. Ce n’est pas une critique personnelle — c’est une observation sur l’écart de compétence opérationnelle entre l’analyste et le prestataire, qui produit des décisions de sourcing systématiquement sous-optimales.
Que voit un prestataire qu'un analyste ne peut pas voir ?
L’économie réelle de la livraison : combien coûte vraiment chaque maillon, où se nichent les marges de compression, quels choix d’architecture feront sauter un SLA dans six mois. Comment négocier un SLA avec un service achats qui ne sait pas ce qu’est un SLA. Comment gérer une escalade quand un système legacy « ne peut pas être mis à jour » mais doit fonctionner. Cette connaissance vit dans les boîtes qui livrent, pas dans les benchmarks de marché.
Pourquoi le coût par journée-homme ne suffit-il plus comme métrique ?
Parce qu’avec l’IA, la journée-homme est devenue une unité variable. Un prestataire qui intègre bien les agents de coding livre en 3 jours ce qu’un autre livre en 10. Les comparer au coût horaire les fait paraître équivalents sur le papier et différents en résultat. Il faut des métriques d’outcome — time-to-prod, taux de défauts, respect des SLA — que l’advisory traditionnel n’utilise pas faute de connaissance de la livraison.
Que devraient faire les frameworks d'advisory ?
Intégrer les prestataires avec expérience de livraison comme sources primaires, pas seulement comme objets d’évaluation. Aujourd’hui, le marché de l’advisory définit les best practices de sourcing sans que ceux qui livrent aient voix au chapitre. Résultat : un déficit informationnel qui coûte de l’argent réel à acheteurs comme vendeurs, et qui ne se comble qu’en reconnaissant que la compétence opérationnelle est un input, pas du bruit.