
Demande à un responsable technique si l’IA a rendu son équipe plus efficace, et tu auras généralement droit à un temps de réflexion avant la réponse. Pas parce qu’il n’y croit pas. Mais parce que personne ne lui a jamais expliqué ce que « efficace » était censé signifier, ni donné de chiffre pour le vérifier.
Jonas Kröger, directeur senior des solutions clients chez Upsun, passe son temps à discuter avec les personnes qui prennent ces décisions, et le problème sur lequel il se heurte sans cesse n’est pas lié aux outils. C’est plutôt que la plupart des promesses faites actuellement aux responsables techniques ne peuvent en réalité pas être vérifiées.
« Il y a des responsables qui s’inquiètent des dépenses, c’est vrai, mais aussi du décalage entre les promesses de gains d’efficacité et la réalité », explique Kröger. « La plupart des équipes à qui on parle aujourd’hui ne mesurent pas leur efficacité. Alors comment promettre un gain d’efficacité si on n’a rien pour le prouver ? »
Ce n’est pas une critique à l’encontre de ces équipes. C’est simplement vrai pour la plupart des services d’ingénierie, qu’ils utilisent l’IA ou non : temps de cycle, délais de révision, taux d’incidents… Peu d’entre eux faisaient l’objet d’un suivi régulier avant l’arrivée des agents. Ce qui signifie que la partie « avant » de chaque affirmation du type « X % plus efficace » est généralement absente. Personne ne ment. Il n’y a tout simplement rien à quoi se comparer.
Même quand les équipes ont un chiffre à avancer, c’est souvent le mauvais. Kröger a expliqué pourquoi le volume de pull requests, un indicateur auquel beaucoup d’équipes se réfèrent en premier, ne tient pas la route.
« Est-ce que le rendement est satisfaisant ? On a plus de PR. Est-ce que c’est plus efficace ? Je ne sais pas trop », a-t-il déclaré. « Sortir plus de fonctionnalités plus souvent ne veut pas forcément dire que tu es plus efficace. C’est juste plus de choses inutiles. Du coup, ça peut même être moins efficace, parce que tout à coup, le nombre de demandes d’assistance ou d’incidents augmente. »
Lancer plus de code plus vite n’est pas forcément un progrès. Si c’est du mauvais code, ou du code que personne n’a eu le temps de bien réfléchir, le volume ne fait que déplacer le coût en aval, vers les tickets d’assistance et les appels d’incident, où il est plus difficile de remonter à la source du problème.
La solution que Kröger propose n’est pas un nouveau tableau de bord spécifique à l’IA. C’est un ancien outil que la plupart des équipes connaissent déjà, mais qu’elles utilisent rarement de manière cohérente.
« Les indicateurs DORA existent depuis un moment pour évaluer les équipes logicielles », a-t-il déclaré, « et il faudrait peut-être établir un lien plus évident avec ces éléments. »
DORA (fréquence de déploiement, délai de mise en œuvre, taux d’échec des changements et temps de reprise) a été conçu pour répondre précisément à cette question concernant la livraison logicielle en général. La plupart des argumentaires des fournisseurs passent directement à côté et partent à la recherche d’une métrique qui semble propre à l’IA. Le point de vue de Kröger est plutôt l’inverse : relier cette nouvelle activité à un cadre qui repose déjà sur des années de sens partagé, plutôt que d’en inventer un nouveau sur lequel personne n’est encore d’accord.
Les dépenses sont l’autre domaine où le fossé entre les promesses et les preuves se manifeste. « Comment puis-je contrôler les dépenses ? » sera sans aucun doute une objection, a déclaré Kröger, « car surtout en ce moment, si tu fournis ta clé API et que tu n’as aucun moyen de la plafonner, de la contrôler ou d’en avoir une visibilité, ça va poser problème. »
Et derrière la question des coûts se cache une autre, plus floue : est-ce que dépenser plus permet vraiment d’obtenir de meilleurs résultats ? « Ils sont perdus », a déclaré Kröger à propos de la plupart des organisations qui tentent de répondre à cette question. « Ils ne savent pas. Et qui le sait, d’ailleurs ? » Cette incertitude explique en grande partie pourquoi les grandes organisations continuent de dépenser malgré tout, a-t-il suggéré, car la peur de se faire distancer l’emporte sur le fait de ne pas encore avoir la preuve que ces dépenses portent leurs fruits.
Tout ça ne veut pas dire que les responsables techniques hésitent à adopter l’IA. L’analyse de Kröger est plutôt le contraire : ceux qui sont les plus avancés ne se demandent pas s’il faut utiliser un processus automatisé ; ils se demandent comment étendre ce qui fonctionne déjà au-delà d’une seule équipe, et personne ne leur propose d’aide pour ça.
Kröger ne s’appuie pas sur la différenciation du produit pour défendre son point de vue. Selon lui, la différenciation ne viendra ni de l’agent ni du modèle sous-jacent, puisque cette couche est relativement similaire partout. Elle provient plutôt des outils d’accompagnement et des services qui l’entourent : comprendre où une équipe est réellement bloquée, et mettre en place l’intégration et le soutien au processus d’intégration qui lui permettront de se débloquer.
C’est autant un problème de service que de produit, et c’est justement cette partie qui est souvent négligée quand un argumentaire met en avant les fonctionnalités au lieu de se demander comment une équipe saura si ça a marché.
C’est justement ce fossé, entre les promesses ambitieuses sur le produit et le travail peu glamour qui consiste à les valider et à les déployer à grande échelle, qu’Upsun Dispatch™ cherche à combler pour les responsables techniques : une visibilité sur les coûts intégrée dès le premier jour, l’intervention humaine par défaut plutôt que comme un ajout de dernière minute, et un point de départ précis et honnête au lieu d’une promesse de tout résoudre d’un seul coup.