Un prestataire ICT se compose de couches de travail qui ont peu de rapport entre elles. Il y a la construction et la maintenance de code, il y a le traitement des tickets et des incidents, il y a l'architecture et la conception, il y a la gestion de projet vis-à-vis du client, et il y a le presales : devis, preuves de concept, justification technique d'un appel d'offres. Entre ces catégories, les heures varient énormément selon la mission. Un service de support fonctionne sur le volume et la répétition. Une équipe d'architecture fonctionne avec un petit nombre de personnes très expérimentées. Le résultat d'un contrat est déterminé par la couche à laquelle le client accorde le plus de poids, et cela diffère selon l'appel d'offres, le client et le moment du projet.
Les trois catégories qui se retrouvent partout — l'IA reprend la tâche, l'IA travaille vers un résultat qu'un humain approuve ou rejette, ou le travail reste un travail humain — traversent tout le secteur ICT, et pas de manière uniforme. Le traitement des tickets pour des problèmes connus est en partie automatisable ; le premier tri, la reconnaissance d'un schéma, la proposition d'une solution issue de cas antérieurs. La génération de code pour des morceaux de logiciel routiniers glisse vers l'IA avec un relecteur qui approuve le résultat. Les décisions d'architecture, la traduction d'un souhait client vague en un système fonctionnel, et le maintien de la confiance chez un donneur d'ordre restent pour l'instant un travail humain, car ils nécessitent un jugement qui ne peut être extrait d'un schéma dans des données existantes.
Le glissement que cela provoque ne porte pas sur la question de savoir si l'IA est douée pour coder. Il porte sur ce qui arrive à la comparaison entre fournisseurs dès qu'une partie de ce travail s'effectue toute seule. Le temps de réponse sur le support était le résultat des effectifs et de la planification ; si le tri s'effectue en grande partie de manière automatisée, la rapidité n'est plus la preuve d'une bonne équipe, mais d'un système bien configuré, et ce système, les concurrents peuvent tout aussi bien l'acheter ou le construire. Ce qui reste alors comme distinction, ce n'est pas la rapidité elle-même, mais ce qui se passe dans les cas où le système ne résout pas le problème — qui parvient à s'en sortir et qui laisse un client attendre.
Le même schéma se retrouve dans les processus de devis. Constituer une proposition technique à partir de composants existants est un travail en partie automatisable. Dès que cela se produit chez plusieurs parties dans un appel d'offres, l'endroit où un client voit encore une différence se déplace : non plus la rapidité de la proposition, mais la question de savoir si la proposition est adaptée à cette situation spécifique, et qui peut l'expliquer sans se rabattre sur un modèle type.
Qu'une entreprise ICT ait déjà organisé cela de cette manière dépend de l'usage qu'elle fait de son personnel. Une entreprise qui affecte encore en grande partie ses architectes expérimentés à l'écriture de code standard dispose de peu de capacité pour la conversation avec le client où se joue le contrat. Une entreprise qui a déjà déplacé ce travail — l'IA pour la partie routinière, les humains pour le jugement — a libéré ces heures pour précisément l'élément sur lequel on l'emporte désormais. Ce n'est pas un choix qui se fait en un trimestre ; il découle de décisions antérieures concernant les outils, qui fait quel type de travail, et quelle confiance une organisation accorde au contrôle des résultats automatisés. Ce qu'un employeur fait de son personnel dans ce cadre relève de l'employeur ; des exigences légales propres s'appliquent à cela, indépendamment de la question de savoir quel travail est techniquement transférable.
Cette dynamique n'est pas propre à l'ICT. Le même glissement — du volume et de la rapidité vers le jugement et l'explication — se déroule différemment dans les services financiers, où le conseil et l'évaluation des risques constituent le point d'appui, et différemment encore dans le secteur de la construction, où la planification et le calcul évoluent mais où l'exécution sur le chantier reste un travail humain. La question de savoir quel travail, dans cette entreprise spécifique, a déjà été déplacé et lequel ne l'a pas été, peut trouver une réponse grâce à [un scan du travail qui évalue, tâche par tâche, si l'IA la reprend, la reprend partiellement sous contrôle, ou ne la reprend pas](https://ftetoai.nl) — une étape distincte, indépendante de la comparaison avec les concurrents.
Le risque de ce glissement n'est pas qu'un fournisseur perde, mais qu'il ne sache pas sur quoi. Un devis qui affirme être plus rapide, un site web qui promet de la stabilité, un argumentaire commercial qui s'appuie sur l'expertise — ce sont autant d'affirmations, et les affirmations ne deviennent un avantage que si elles peuvent être étayées face à ce qu'un client voit ailleurs. Celui qui a constaté un retard sur une dimension peut consulter une approche pour rattraper un retard sur une dimension spécifique pour connaître les options possibles, et celui qui veut étayer une affirmation avant qu'un client ne la questionne trouvera dans une vérification des affirmations relatives à sa propre qualité comment procéder de manière systématique.
Identifiez sur quoi votre entreprise pense l'emporter — rapidité, prix, expertise, fiabilité — et vérifiez lesquelles de ces affirmations vous pouvez étayer aujourd'hui par des preuves face à un concurrent. C'est précisément ce que fait le test de dimension gratuit : non pas un benchmark complet, mais un premier aperçu des affirmations qui tiennent solidement et de celles qui restent encore en suspens. Le benchmark concurrentiel complet, avec une matrice de preuves par dimension, est en cours de développement.