J’entendais parler de machine learning et d’intelligence artificielle depuis des années bien avant que les LLM fassent partie du travail quotidien. Dans l’entreprise, nous avions déjà traversé plusieurs vagues de tentatives pour extraire plus de valeur de nos données. Certaines passaient par des modèles, d’autres étaient plus proches de l’analytique et de l’automatisation, mais la même question revenait toujours : est-ce que cela créait vraiment de la valeur d’une façon qui justifiait l’effort?
Un des premiers exemples était un modèle que nous avions construit pour optimiser ce que nous montrions aux utilisateurs. D’une certaine façon, cela fonctionnait. Nous réussissions à augmenter les clics et à amener plus de gens jusqu’à la page d’inscription. Mais la boucle complète ne tenait pas. Le taux de conversion ensuite était trop faible, et le coût d’exploitation du modèle finissait par être plus élevé que la valeur générée. Le projet a fini par être arrêté.
Nous avons exploré d’autres choses après cela : des outils de recommandation par des tiers, des pipelines de données pour comprendre l’usage réel au lieu de nous fier uniquement à l’intuition, et quelques expériences autour de ce que les gens regardaient réellement et de la façon d’en tirer quelque chose de plus utile. Certaines de ces initiatives valaient la peine, mais elles avaient souvent la même limite. Nous pouvions améliorer quelque chose localement sans être vraiment certains que cela comptait au niveau de l’entreprise.
C’était le contexte dans lequel les LLM ont commencé à devenir largement accessibles. Ce qui a changé n’était pas seulement la technologie elle-même. C’est que l’IA a cessé d’être surtout un sujet traité à travers des projets spécialisés pour devenir un outil que les gens pouvaient essayer directement dans leur propre travail. Au lieu d’être quelque chose qu’un petit groupe expérimentait pour le compte de l’entreprise, elle devenait soudainement un outil que presque n’importe qui pouvait utiliser pour rédiger un document, résumer de l’information, explorer une idée, préparer un message ou structurer une tâche.
Le développement était un terrain évident, et beaucoup d’attention s’est portée là-dessus en premier, mais il n’a jamais été question uniquement de code. Le vrai changement était plus large. Des gens un peu partout dans l’entreprise pouvaient commencer à tester ces outils sur la forme réelle de leur travail quotidien, et cela a créé de la friction immédiatement. Nous avions déjà des règles de sécurité sur ce qui pouvait ou non être partagé dans des documents, des courriels et d’autres systèmes. Puis, tout à coup, nous avions des outils dans lesquels les gens pouvaient coller presque n’importe quoi dans une invite.
Ce n’était pas une inquiétude théorique. Nous avions déjà de la difficulté avec des choses de base, comme de l’information partagée au mauvais endroit. Sous cet angle, les LLM ressemblaient moins à une amélioration propre et plus à une nouvelle source de risque arrivée avant que la plupart des organisations soient vraiment prêtes. Cela n’aidait pas non plus que les contrôles entreprise soient encore immatures dans beaucoup des outils que les gens voulaient utiliser. L’accès était fragmenté, certains achetaient leur propre abonnement, et l’intérêt progressait plus vite que la gouvernance. Nous avons fini par passer à un accès offert par l’entreprise, pas seulement pour les développeurs, mais plus largement, une fois que les outils ont été suffisamment mûrs pour le permettre.
Avec le recul, je ne pense pas que ce départ un peu désordonné ait été entièrement une mauvaise chose. Beaucoup de gens voulaient avoir accès à ces outils avant même de savoir comment ils allaient les utiliser. Il y avait de la curiosité, bien sûr, mais aussi la crainte de prendre du retard. Sur papier, il aurait été facile de dire qu’il fallait attendre d’avoir une structure plus claire, plus de formation et des cas d’usage mieux définis. En pratique, je pense que cela aurait surtout retardé l’apprentissage réel.
Ce genre d’outil est difficile à comprendre à partir d’un simple document de politique ou d’une courte démonstration. Les gens les apprennent quand ils essaient de résoudre quelque chose qui compte pour eux. Quand on est son propre stakeholder, la boucle de rétroaction devient beaucoup plus concrète. On voit si l’outil aide vraiment, s’il ralentit, ou s’il produit quelque chose qui demande encore trop de correction pour être rentable. C’est aussi pour cela que je pense que les organisations devraient encourager les gens à réfléchir tôt à la place que l’IA peut prendre dans leur travail, plutôt que d’attendre qu’un mode d’emploi parfait arrive avec l’outil.
Si les gens restent passifs et attendent que quelqu’un d’autre définisse tous les usages valides, ils risquent d’obtenir l’accès sans jamais vraiment apprendre à s’en servir. Pour moi, cet apprentissage a pris du temps. Il ne s’agissait pas seulement de découvrir des prompts ou de comparer des produits. Il s’agissait surtout de développer un certain instinct pour reconnaître les tâches où l’outil pouvait réellement aider. Les tâches répétitives étaient un point de départ évident, surtout lorsqu’il existait déjà une forme reconnaissable dans le travail. La rédaction en était un autre. Les résumés, la restructuration d’information, l’exploration d’options et la préparation d’une première version que je pouvais ensuite revoir et corriger se sont révélés utiles de différentes façons.
Avec le temps, j’ai commencé à voir que la valeur venait souvent moins du remplacement du travail que de la réduction de la friction pour se mettre en mouvement. Cette logique s’applique bien au-delà du développement. Il y a beaucoup d’attention sur la génération de code plus rapide, et dans certains contextes cette valeur est bien réelle. Mais l’occasion la plus large se trouve dans tout le travail autour du code, et au-delà : l’écriture, l’analyse, la synthèse, la préparation, la communication et d’autres formes de travail sur ordinateur où une première version utile ou une réponse structurée peut faire gagner du temps sans retirer la responsabilité.
Ce qui compte, c’est d’apprendre où l’outil s’insère et où il ne s’insère pas. Un bon candidat est souvent une tâche qu’on fait assez souvent pour en reconnaître le motif, dont le résultat peut être revu rapidement, et où le risque d’une mauvaise réponse reste encore gérable. Cela ne demande pas toujours un LLM, mais les LLM sont souvent utiles lorsque la tâche comporte du langage, de l’ambiguïté ou une structure encore incomplète plutôt que des règles entièrement fixes.
La partie plus difficile, c’est que la commodité peut tranquillement devenir une dépendance. Si on délègue trop, surtout dans les domaines où le jugement compte, on risque de devenir moins connecté au travail lui-même. Cela ne se voit pas forcément tout de suite. Dans certains cas, cela revient rapidement quand on se replonge dedans. Dans d’autres, surtout quand le domaine évolue vite, prendre trop de distance avec le travail sous-jacent peut rendre plus difficile de voir ce qui a changé. C’est un des compromis que je garde en tête. Gagner de l’efficacité est utile, mais pas si cela affaiblit progressivement la capacité à penser clairement à propos d’un travail dont on reste responsable.
Cela me ramène aussi à une question plus ancienne. Ce n’est pas parce qu’un outil donne l’impression qu’une partie du travail va plus vite qu’il crée automatiquement de la valeur de façon significative. Les efforts plus anciens autour de l’IA m’ont appris que l’amélioration locale et l’impact réel ne sont pas toujours la même chose. Les LLM sont peut-être plus faciles à adopter et plus faciles à ressentir au quotidien, mais la question reste importante : quelle est la valeur réelle une fois qu’on compare le gain au coût, au temps de révision, au risque et à la perte d’attention qui peut venir d’une dépendance excessive?
C’est pour cela que je reviens toujours au même point : ces outils sont utiles, mais ce sont quand même des outils. Ils demandent de la pratique, du jugement et des limites. La sécurité compte encore. Le contexte compte encore. La révision compte encore. Si l’outil aide à mieux réfléchir, à avancer plus vite ou à réduire des tâches répétitives, c’est utile. Mais je ne pense pas que l’objectif soit de lâcher complètement le volant.
Ce qui a changé pour moi, ce n’est pas que l’IA s’est soudainement mise à avoir toutes les réponses. C’est qu’elle est devenue assez accessible pour être apprise dans l’usage quotidien. Mais cela ne fonctionne que si les gens sont prêts à y consacrer un vrai temps, à rester attentifs à l’endroit où elle aide, et à garder la responsabilité du résultat. Utilisée de cette façon, elle peut ouvrir de nouvelles manières de travailler. Utilisée sans assez d’attention, elle peut tout aussi facilement créer du bruit, du risque et de la distance par rapport au travail qu’il faut encore comprendre.
- Patrick