Il y a quelques semaines, j’ai reçu le rapport d’un cabinet d’advisory connu qui évaluait le marché des services IT dans notre segment. Je l’ai lu attentivement, parce que mes clients lisent ce genre de choses avant de choisir avec qui travailler. Le rapport était bien écrit, les analyses de marché solides, les tendances correctes. Et pourtant, en le lisant, je ne cessais de penser : qui a écrit ça n’a jamais livré un projet logiciel à un client de la fonction publique italienne. N’a jamais négocié un SLA avec un service achats qui ne sait pas ce qu’est un SLA. N’a jamais expliqué à un dirigeant de santé pourquoi son système legacy ne peut pas être simplement « mis à jour » sans refaire toute l’intégration avec le SI régional.
Pas une critique. Une observation sur un angle mort structurel du marché de l’advisory IT. Les personnes qui conseillent l’achat de techno, dans la grande majorité, n’en ont jamais vendu. Et celles qui en vendent et en livrent n’ont pas voix au chapitre dans la définition des best practices de sourcing. Résultat : un déficit informationnel qui coûte de l’argent réel à ceux qui achètent et à ceux qui vendent.
Je le dis en connaissance de cause. Je gère une petite ICT qui vit de contrats avec des clients mid-market et de la fonction publique. J’ai écrit des devis, négocié des contrats, défini des SLA, géré des escalades, subi des pénalités, livré des projets en retard et en avance. J’ai vu le marché des services IT du côté du tablo où les analystes de sourcing voient rarement. Et ce que je vois ne correspond pas toujours à ce que les frameworks d’advisory décrivent.
Premier angle mort : le pricing
La plupart des frameworks évaluent les prestataires au coût par jour-homme ou point fonction. Métriques compréhensibles, comparables, fondamentalement obsolètes. L’IA rend la relation entre temps de travail et valeur livrée complètement non linéaire. Une équipe de cinq avec coding agentique livre en une semaine ce qu’une équipe de quinze livrait en un mois. Valeur identique pour le client. Coût en jours-homme : un cinquième. Si le client paie au jour-homme, le prestataire a un incitatif pervers à ne pas adopter l’IA — il facture moins. S’il l’adopte et que le client continue à valoriser au jour-homme, il paraît cinq fois plus cher par jour, même si le coût total du projet baisse.
Pas un problème théorique. Je l’affronte chaque mois en présentant des devis. J’ai cessé de chiffrer au jour-homme il y a plus d’un an. Je chiffre au livrable : voilà le résultat, voilà le prix, voilà les conditions. Certains clients apprécient. D’autres — surtout dans la PA, où les appels d’offres sont structurés autour des jours-homme — ne savent pas le gérer. Le cadre d’achat ne prévoit pas un prestataire qui livre plus de valeur en moins de temps.
Deuxième angle mort : la compliance comme critère de sourcing
Les frameworks commencent à l’ajouter. Mais comme case à cocher : « le prestataire est-il conforme RGPD ? oui/non ». Radicalement insuffisant. La compliance n’est pas binaire. Un prestataire peut avoir une politique privée sur le site et aucun mécanisme technique de data minimization dans le code. Déclarer être AI Act compliant sans avoir idée de ce qu’est une évaluation de risque pour des systèmes IA à haut risque. Cocher « SBOM » sans avoir une pipeline qui génère le SBOM automatiquement à chaque build.
Un framework sérieux, dans le contexte EU d’aujourd’hui, devrait évaluer la compliance non comme déclaration mais comme capacité technique. Le prestataire a-t-il un processus documenté de vulnerability handling ? Sa pipeline CI/CD inclut-elle un scan des dépendances ? Ses SBOM sont-ils générés automatiquement ou compilés à la main ? Son software a-t-il des tests automatiques vérifiant des propriétés de privacy ? Ces questions sont plus révélatrices que toute certification. Et seules les personnes ayant l’expérience opérationnelle savent les formuler.
Troisième angle mort : les PME IT
Le marché de l’advisory est structuré autour des grands SI. Les matrices, les Magic Quadrant, les Wave, les Provider Lens : tous calibrés sur des entreprises facturant des centaines de millions. Les PME IT — qui en Europe représentent la grande majorité des prestataires de software — sont invisibles. Pas parce qu’elles ne livrent pas de la valeur, mais parce qu’elles n’ont pas l’échelle pour participer aux processus d’évaluation des analystes.
Paradoxe. Le client mid-market — la boîte de 200-500 personnes, l’ARS, la mairie, la chambre de commerce — lit les rapports et n’y voit que les grands noms. Mais les grands noms ne servent pas le mid-market italien, ou le servent avec des juniors supervisés par un partner qu’on ne voit jamais. Le prestataire qui livre vraiment — la PME locale de dix personnes, un senior par projet, relation directe avec le décideur — n’apparaît dans aucun framework. Gap informationnel total.
Quatrième angle mort : la gouvernance des contrats
Les frameworks sont bons à évaluer la phase de sélection : choisir, comparer, négocier. Bien moins bons sur la phase d’exécution : surveiller, intervenir quand ça va mal, gérer le changement de scope. Or, dans mon expérience, 90 % des problèmes ne viennent pas du choix du prestataire mais de la gestion du contrat ensuite.
J’ai vu des projets échouer non par incompétence du prestataire mais parce que le client n’avait pas de gouvernance interne pour décider des changements d’exigences. Vu des SLA négociés au centime que personne ne surveillait. Vu des pénalités contractuelles jamais appliquées parce que le client dépendait trop du prestataire pour le sanctionner. Patterns récurrents que tout prestataire connaît intimement et que les frameworks d’advisory traitent comme des exceptions.
Cinquième angle mort : qualité technique et business
Peut-être le plus profond : la relation entre qualité technique et résultat business. Les frameworks évaluent prix, track record, taille d’équipe, certifications. Rarement la qualité technique du logiciel produit. Combien de tests automatiques dans le codebase ? Quelle couverture ? Comment l’archi est-elle structurée ? Le code est-il maintenable ? La doc est-elle à jour ? Ce sont les dimensions qui déterminent le TCO réel — pas le déclaré — et les analystes de sourcing ne sont pas équipés pour les évaluer.
Résultat : le marché récompense la capacité à vendre — présentations convaincantes, références solides, équipes nombreuses — plutôt que la capacité à construire. Et c’est ce qui explique pourquoi tant de projets IT coûtent le double du prévu et livrent la moitié de la promesse : la sélection se fait sur des critères qui ne prédisent pas la qualité de l’exécution.
J’écris ces choses non pour le plaisir de critiquer un secteur que je respecte et qui, franchement, m’intéresse. Je les écris parce que je crois que le marché de l’advisory IT est à un point d’inflexion. L’IA change l’économie de la livraison. La compliance européenne change les critères d’achat. Le mid-market européen a besoin de frameworks qui ne soient pas des versions simplifiées de ceux de l’enterprise. Et les prestataires IT — ceux qui construisent et livrent vraiment le software — ont un savoir opérationnel qui, intégré dans les frameworks d’advisory, les rendrait beaucoup plus utiles.
Je ne prétends pas avoir la solution. Mais après quinze ans de l’autre côté du tablo, je sais quelles questions devraient être posées et ne le sont pas. Je sais quelles métriques prédisent le succès d’un projet et lesquelles prédisent seulement la qualité de la présentation initiale. Je sais ce qui change dans le pricing quand l’IA entre dans le cycle de livraison. Je sais ce que veut dire compliance dans un codebase de production, pas dans un document de policy.
C’est un savoir que le marché de l’advisory n’a pas — non par incompétence, mais par séparation structurelle d’avec la livraison. Et c’est peut-être le moment de bâtir un pont.
Ce qu'il faut retenir
Le coût par journée-homme est obsolète : l’IA en fait une unité variable, et évaluer ainsi punit qui l’a adoptée.
La compliance est traitée comme une case à cocher, pas comme une capacité technique — seul qui a vécu la livraison sait quelles questions la révèlent.
Les PME IT livrent le mid-market européen mais sont invisibles dans des frameworks calibrés sur les grands SI : le gap informationnel est total.
90 % des échecs ne viennent pas du mauvais choix de prestataire mais de la mauvaise gestion du contrat ensuite — phase que l’advisory évalue à peine.
Le marché récompense la capacité de vendre, pas celle de construire ; d’où des projets qui coûtent le double et livrent la moitié.
Questions & réponses
Qu'est-ce qui rend un rapport d'advisory bien écrit mais opérationnellement aveugle ?
Son auteur a analysé le marché avec rigueur mais n’a jamais livré un projet logiciel pour la fonction publique italienne, jamais négocié un SLA avec un service achats, jamais expliqué à un dirigeant santé pourquoi son legacy ne peut être « mis à jour » sans refaire l’intégration au SI régional. Les analyses de marché sont solides, les conclusions opérationnelles non. On produit des décisions de sourcing qui paraissent informées et ne le sont pas.
Pourquoi la métrique « coût par journée-homme » devient-elle obsolète ?
Parce que l’IA en fait une unité variable. Un prestataire qui intègre bien des agents de coding livre en trois jours ce qu’un autre livre en dix. Les comparer au coût horaire les fait paraître équivalents sur le papier et révèle la différence seulement au 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 ne voient pas les frameworks d'advisory de l'économie réelle des services IT ?
Combien coûte vraiment chaque maillon de la livraison, où se nichent les marges de compression, quels choix d’archi feront sauter un SLA dans six mois. Ces données existent dans les boîtes qui livrent, pas dans les benchmarks de marché. Un framework peut décrire le « quoi » du sourcing, mais sans le « comment » de la delivery, il produit des décisions plausibles, pas informées.
Qu'est-ce qu'un acheteur IT devrait demander à un prestataire avant de choisir ?
Pas seulement combien il facture, mais comment. Comment il gère une escalade quand un SLA saute. Demander à parler à quelqu’un de l’équipe qui a livré un projet similaire et a dû le défendre six mois plus tard. Les réponses à ces questions disent plus du prix par jour-homme que toute colonne de tableur — et ce sont précisément les questions que les rapports d’advisory n’aident pas à formuler.