Le secteur ICT est constitué pour une grande part de travail qui peut se diviser en étapes reconnaissables : écrire du code selon un cahier des charges, tester par rapport à des critères établis, tenir la documentation à jour, trier des tickets, configurer une infrastructure, composer des rapports. À côté de cela, il y a du travail qui ne se laisse justement pas capturer en étapes : un choix d'architecture qui a des répercussions sur des années, un client qui décrit un problème que personne n'a encore résolu, une équipe qui doit mettre en balance un délai et une exigence de qualité. Ces deux types de travail se retrouvent dans les mêmes fonctions, souvent chez la même personne le même jour.
Ce mélange explique pourquoi l'IA n'arrive pas ici comme un projet mais comme un glissement insidieux. Une partie du travail a toujours été intensive en main-d'œuvre sans être complexe : convertir du code d'un langage vers un autre, générer des scripts de test, parcourir des journaux à la recherche d'un schéma connu. Dès que l'IA reprend cette partie, entièrement ou en partie, rien ne change à la stratégie sur papier — la feuille de route, la promesse client, le niveau de service restent en place — mais l'hypothèse sous-jacente, à savoir combien de personnes et d'heures sont nécessaires pour tenir cette promesse, n'est plus automatiquement vraie.
Ce qui se passe dans l'ICT ne peut pas se résumer par « l'IA remplace les programmeurs ». Le travail se divise en trois catégories qui traversent presque toutes les fonctions. Certaines tâches, l'IA peut les exécuter de façon autonome : générer du code structuré, effectuer des traductions entre systèmes, réaliser des tests répétables. D'autres tâches se déroulent partiellement : l'IA fait une proposition — une modification de code, une estimation de risque, un résumé d'incident — et une personne approuve ou rejette, avec une raison consignée. Et une troisième catégorie reste du travail humain : la conversation avec un client sur ce qu'il veut vraiment dire, la décision de mettre ou non un système en production, la responsabilité de ce qui tourne mal.
La répartition entre ces trois catégories n'est pas figée. Dans une entreprise avec beaucoup de systèmes existants et peu de documentation standardisée, la part de la troisième catégorie est plus élevée que dans une entreprise avec une infrastructure moderne et bien documentée. Dans une équipe qui organise le contrôle comme un élément fixe du processus — quelqu'un qui évalue réellement les propositions de l'IA, sans simplement les valider en cliquant — davantage de travail se déplace vers la deuxième catégorie sans perte de qualité. Dans une équipe sans ce contrôle, l'IA reste limitée à des expériences isolées, et peu de choses changent, même si la technologie est disponible.
La raison pour laquelle ceci concerne la table du comité de direction et pas seulement le service informatique, c'est que les stratégies dans ce secteur reposent souvent sur une hypothèse de capacité : combien de capacité de développement est nécessaire pour tenir la feuille de route, combien de capacité de support pour maintenir le niveau de service, combien de temps de seniors pour former les juniors. Si l'IA reprend une partie du travail de la première ou de la deuxième catégorie, la quantité d'heures et de capacité en équivalents temps plein libérées change — pas selon un pourcentage fixe, cela dépend des systèmes, de la discipline dans le processus et du degré de contrôle humain, mais la direction du déplacement, elle, est certaine.
La question stratégique n'est alors pas de savoir si l'IA reprend du travail, mais si le plan repose encore sur l'ancienne répartition. Une feuille de route qui compte sur une capacité de développement fixe, un modèle tarifaire qui part d'un nombre fixe d'heures de support par client, un parcours de formation construit sur la présomption que le travail des juniors reste identique — ce sont là autant d'hypothèses qui peuvent devenir caduques sans préavis à cause de ce déplacement. Personne ne les retire formellement ; elles restent simplement inscrites dans le plan tandis que la réalité sous-jacente change. C'est un schéma différent de celui, par exemple, des services financiers, où la réglementation détermine en partie le rythme de l'automatisation, ou de la construction, où l'exécution physique impose une autre limite à ce que l'IA peut reprendre. Dans l'ICT, la limite est souvent moins physique et moins juridique, et donc plus rapide à se déplacer — ce qui rend le risque d'une hypothèse tacitement obsolète plutôt plus grand que plus petit.
Deux entreprises du même sous-secteur peuvent se trouver dans des situations très différentes à cet égard, et cette différence tient rarement à la disponibilité des outils d'IA — ceux-ci sont accessibles aux deux. Elle tient au fait qu'il existe ou non un mécanisme de contrôle fonctionnel qui évalue les résultats de l'IA avec une raison consignée, que la documentation et les systèmes soient ou non en ordre pour que l'IA puisse en faire quelque chose, et que la direction ait ou non fait vérifier récemment les hypothèses sous-jacentes à la stratégie par rapport à ce qui a déjà changé opérationnellement. Les entreprises qui n'ont pas fait ce dernier point pilotent une stratégie qui reste correcte sur papier, alors que l'hypothèse de capacité qui la sous-tend a depuis longtemps été dépassée.
Ce déplacement touche également la question de savoir qui doit être présent lors d'une telle vérification — pas seulement la direction, mais aussi les personnes qui voient réellement le travail changer, comme décrit dans un aperçu de qui doit participer à une revue stratégique. Dans la mesure où ce déplacement touche à des décisions concernant le personnel, des exigences légales propres s'appliquent à cet égard ; cette page traite de la stratégie, pas de ces décisions.
La question sous-jacente — quel travail dans cette entreprise peut réellement être repris par l'IA, quel travail partiellement, et quel travail reste du travail humain — trouve sa réponse dans le scan de travail de FTE TO AI, tâche par tâche, plutôt que sur la base d'une estimation pour tout le secteur. Avant d'en arriver à ce scan, il y a une étape plus modeste : la vérification gratuite des hypothèses, un bref parcours dans lequel vous identifiez vos principales hypothèses stratégiques et voyez, pour chacune, quand elle a été réellement confirmée pour la dernière fois. Cela rend visible quelles hypothèses tiennent encore solidement et lesquelles se sont discrètement mises à glisser. L'épreuve de pression stratégique complète, avec le regard extérieur mis en parallèle avec l'auto-évaluation de la direction, est en cours de préparation.
Stel uw vraag. Vaak zit de echte vraag een laag dieper — daar mag ik naar vragen.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.