Le secteur ICT est constitué de travail qui se laisse facilement décomposer en étapes répétables et de travail qui, au contraire, ne s'y prête pas. Écrire du code, tester, documenter, trier des tickets, évaluer le monitoring, déployer des configurations : bon nombre de ces tâches ont une structure fixe et un critère d'évaluation clair. Vient ensuite le travail qui repose sur des choix architecturaux, le contexte client, des arbitrages de sécurité et la décision de savoir si un système part ou non en production. Cette distinction déterminant où l'IA reprend déjà des tâches aujourd'hui, où le toezicht humain reste nécessaire, et où le travail humain demeure au cœur du métier.
Les circonstances qui orientent le résultat ne sont pas uniformes. Une équipe qui travaille avec une base de code bien documentée et des standards de test clairs peut plus facilement transférer des tâches qu'une équipe qui fonctionne sur une connaissance tribale et des accords oraux. Une organisation avec une structure de revue établie peut intégrer le toezicht sur les résultats de l'IA dans un processus existant ; une organisation sans cette structure doit d'abord la construire avant qu'un transfert ne soit responsable.
Dans certaines parties du secteur, le changement est déjà visible. Les suggestions de code, la génération de tests et les mises à jour de documentation sont, dans certaines équipes, largement produites par l'IA, un développeur approuvant ou rejetant sur la base de la fonctionnalité et de la lisibilité. Dans d'autres équipes, exactement le même travail se fait encore entièrement à la main, non pas parce que la situation y est fondamentalement différente, mais parce que les conditions font défaut : pas d'accès aux bons outils, pas de critères de qualité définis, pas de temps réservé pour reconstruire le processus.
Cette différence entre entreprises ne réside que rarement dans la technique elle-même. Elle réside dans la préparation : l'organisation a-t-elle ses données et sa documentation en ordre, un droit de décision est-il attribué à qui évalue les résultats de l'IA, une capacité a-t-elle été libérée pour mettre en place le nouveau processus avant que l'ancien ne soit démantelé. Là où ces conditions manquent, une ambition reste sur papier, même si la technique est déjà disponible.
Une ambition telle que « l'IA soutient nos développeurs » semble univoque, mais exige en pratique une série de capabilities qui ne sont pas présentes d'elles-mêmes : un environnement de test capable de valider du code généré par l'IA, un processus de revue qui ne ralentit pas sous un volume supplémentaire, et des évaluateurs qui savent sur quelle base rejeter une proposition de l'IA. Sans ces capabilities, l'ambition reste une intention sans exécution.
C'est précisément pourquoi les mêmes mots peuvent signifier des choses différentes au sein d'un comité de direction. Le CTO pense à des pipelines automatisés, le directeur opérationnel à moins d'heures libérées pour le support, le responsable RH à une autre répartition des rôles. Aucune de ces interprétations n'est erronée, mais sans un critère partagé, l'ambition reste sans engagement. Comment traduire une vision en quelque chose de mesurable, et non en trois hypothèses distinctes, est décrit dans comment rendre une vision mesurable.
Le secteur ICT n'est pas unique dans sa confrontation à ce changement, même si les points de blocage diffèrent. Dans les services financiers, la question se pose différemment, car le toezicht et la responsabilité y jouent un rôle plus important ; ce qui s'y joue est décrit dans quelles ambitions IA se manifestent dans les services financiers. Dans la construction, le travail physique est un facteur fixe qui limite la reprise par l'IA différemment que dans l'ICT, comme on peut le lire dans quelles ambitions IA se manifestent dans la construction. Et dans le secteur du nettoyage, il s'agit surtout de planification et de contrôle qualité plutôt que de production de code, comme développé dans quelles ambitions IA se manifestent dans le secteur du nettoyage. Le schéma est chaque fois le même : l'ambition ne devient concrète qu'une fois clair quelles capabilities manquent.
Un comité de direction qui décide que l'IA doit reprendre « la plus grande partie du cycle de revue » formule ainsi une ambition qui ne se réalise pas en un trimestre. Ce n'est pas une objection à l'ambition elle-même, mais un signal pour la phaser : quelle capability doit être en place d'abord, laquelle ensuite, et à quel moment l'organisation est-elle pour la première fois en mesure d'évaluer si cela fonctionne. La manière dont ce phasage peut se présenter est décrite dans comment phaser une ambition trop grande pour une année.
Quant aux décisions relatives au personnel qui peuvent découler d'un tel phasage, nous ne nous prononçons pas : quel travail un employeur supprime ou redistribue relève de ses propres obligations légales et de son propre jugement. Ce que nous décrivons, c'est quel travail se laisse transférer, en partie ou entièrement, et dans quelles conditions.
La question sous-jacente n'est pas de savoir si les ambitions IA dans le secteur ICT sont réalistes, mais si cette entreprise spécifique, avec cette base de code, cette équipe et ces processus, est prête à les mettre en œuvre. Quel travail, dans cette entreprise, est réellement susceptible d'être repris par l'IA, tâche par tâche, trouve sa réponse dans le werkscan de FTE TO AI.
Qui souhaite d'abord se faire une idée, sans engagement, peut effectuer le test de préparation gratuit : huit questions courtes, une par dimension, avec une image de là où l'organisation est la plus avancée et la moins avancée. Le test d'ambition complet, avec les quatre couches et les cinq confidence gates, est en cours de construction.
Vertel wat u wilt bereiken, dan kijken we samen wat daarvoor moet staan.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.