Une adoption réussie de l’IA entraîne un second déploiement auquel les entreprises pensent rarement

Il y a environ trois ans, j’ai souscrit pour la première fois à un abonnement payant à un service d’IA et commencé à tester ce qu’il pouvait réellement faire pour moi. Peu à peu, ce qui avait commencé comme une expérimentation personnelle est devenu un petit projet interne, puis des abonnements professionnels pour toute l’entreprise et, finalement, un déploiement de l’IA dans presque tous les services : développement, finance, juridique, marketing et assistance.

La première phase a, dans l’ensemble, fonctionné. En environ six mois, la vitesse de développement en interne a été multipliée par cinq, à peu près. Dans le même temps, un autre chiffre a grimpé : nos dépenses en IA ont été multipliées par environ 15.

C’est à ce moment-là que j’ai compris qu’une adoption réussie de l’IA pouvait aussi créer ses propres problèmes. Une fois la technologie largement utilisée, les règles établies au départ ne fonctionnaient plus. Les coûts risquaient de devenir incontrôlables à mesure que l’IA accédait à davantage de données de l’entreprise et prenait en charge plus de tâches, alors que de nombreux outils restaient contrôlés par des fournisseurs externes.

Alors, que doit faire un PDG lorsque l’adoption de l’IA fonctionne, mais que l’entreprise ne maîtrise plus entièrement la façon dont elle est utilisée ? Essayons de répondre à cette question.

Ne confondez plus utilisation active de l’IA et résultats commerciaux

J’ai tout de suite remarqué que, lors du premier déploiement, les indicateurs d’adoption, comme le nombre d’utilisateurs actifs ou la fréquence d’utilisation, étaient pertinents. En tant que dirigeant, vous voulez savoir si les employés utilisent les outils, lesquels en particulier et si l’IA leur fait réellement gagner du temps. Pourtant, lorsque son utilisation s’étend à toute l’entreprise, ces chiffres deviennent bien moins utiles.

Nous l’avons constaté nous-mêmes. Dès que les gens ont eu accès à des modèles puissants, ils ont commencé à les utiliser pour presque tout. À un moment donné, des employés ont demandé à l’IA quelle heure il était à New York. L’exemple est évidemment absurde, mais il montre à quelle vitesse l’utilisation peut augmenter sans générer de valeur substantielle pour l’entreprise.

Shopify a rencontré un problème similaire après avoir intégré l’IA si profondément que son agent interne, River, rédige désormais jusqu’à la moitié de ses demandes de fusion de code destiné à la production. Pourtant, son PDG, Tobi Lütke, a récemment mis en garde contre ce qu’il appelle les « grenades de contenu bâclé » : des productions générées par l’IA que les employés transmettent sans les vérifier correctement, laissant à quelqu’un d’autre le soin d’examiner, de corriger, voire de résumer le résultat.

Autrement dit, une activité accrue de l’IA peut facilement générer davantage de travail au lieu de créer plus de valeur. Une entreprise peut afficher des chiffres d’utilisation impressionnants et produire d’énormes quantités de contenu, alors qu’une partie de ces productions ne fait que créer une tâche supplémentaire pour quelqu’un d’autre.

C’est ce que les PDG doivent changer. Les invites, les connexions et la consommation de jetons témoignent d’une activité intense au sein du flux de travail. Mais elles ne montrent pas si l’IA est réellement rentable.

La vitesse crée un nouveau goulot d’étranglement

Un dicton dit que la précipitation est mauvaise conseillère. Je pense qu’il s’applique aussi à l’IA, car nous avons appris que rendre les gens « plus rapides » grâce à l’IA ne signifie pas forcément qu’ils ont soudain moins de travail à faire.

Dans le domaine du développement, l’IA permet désormais à notre équipe de produire beaucoup plus de code en un temps équivalent. Mais l’essentiel, c’est que tout ce code doit encore être vérifié avant sa mise en production. Il ne fait aucun doute que la vérification automatisée est utile.

Pourtant, on est encore loin d’une solution à laquelle je ferais aveuglément confiance. Ainsi, si les développeurs passent moins de temps à tout écrire eux-mêmes, ils doivent désormais examiner, tester et évaluer une quantité bien plus importante de contenu.

Autrement dit, le travail ne disparaît pas. Il prend simplement une autre forme.

Cela rend notre multiplication par cinq de la vitesse de développement un peu moins impressionnante, puisque le volume de code nécessitant une intervention humaine augmente en parallèle. Le coût réel d’un flux de travail faisant appel à l’IA comprend aussi le temps passé à vérifier ce qu’elle produit et, surtout, à déterminer si l’on peut faire confiance à ces résultats.

Un second déploiement s’impose

À mon avis, les entreprises ont besoin de ce que j’appellerais un « second » déploiement de l’IA.

Le premier déploiement vise avant tout l’adoption : donner accès aux outils, trouver des cas d’usage et déterminer où la technologie est réellement utile et où elle ne l’est pas. Mais après plusieurs mois d’utilisation réelle, vous disposez déjà de quelque chose de bien plus précieux que des suppositions : vos propres données, qui montrent où les coûts augmentent, quelles équipes obtiennent de meilleurs résultats et où les employés passent trop de temps à vérifier les résultats de l’IA.

C’est donc à ce stade qu’il me semble judicieux de revoir les règles encadrant l’IA, plutôt que de chercher simplement à en élargir l’utilisation. En pratique, je me concentrerais sur trois points :

• Choisir le modèle en fonction de la tâche. Les demandes courantes peuvent être confiées à des modèles plus petits et moins coûteux, tandis que les tâches plus complexes sont réservées aux modèles qui justifient ce surcoût. L’objectif final est d’éviter de payer le prix des modèles de pointe pour des tâches à faible valeur ajoutée.
• Déterminer les situations où le contrôle humain est obligatoire. Pour le code destiné à la production, les documents juridiques ou d’autres productions à fort impact, définissez les étapes auxquelles une personne doit approuver le résultat avant qu’il ne poursuive son parcours dans le flux de travail. Par ailleurs, établissez des règles d’accès aux données sensibles afin que les employés sachent quels modèles peuvent les recevoir et lesquels ne le peuvent pas.
• Établissez un plan de secours, même si vous pensez ne pas en avoir besoin. Si un flux de travail critique dépend d’un fournisseur externe, documentez suffisamment les invites, les intégrations, les flux de données et les dépendances propres au modèle pour pouvoir transférer la charge de travail vers un autre fournisseur en cas d’urgence.

Voilà ce qui distingue le premier déploiement de l’IA du deuxième. Le premier pose la question suivante : où pouvons-nous utiliser l’IA ? Le deuxième demande : où devrions-nous l’utiliser, selon quelles règles et à quel coût ?

Auditer le déploiement avant de passer à l’échelle une nouvelle fois

Une fois que l’adoption de l’IA fonctionne et que le premier déploiement semble réussi, je ne continuerais pas à le développer de la même manière pendant une année supplémentaire. Après environ 90 à 180 jours d’utilisation réelle, je ferais une pause pour auditer ce que l’entreprise a effectivement mis en place.

Cela consiste à mesurer les résultats opérationnels obtenus, à mettre en adéquation le modèle et son coût avec la valeur réelle de la tâche, à déterminer où une vérification humaine reste obligatoire et où un flux de travail peut se rapprocher, dans une certaine mesure, de l’automatisation complète.

Le premier déploiement prouve que l’IA peut rendre l’entreprise plus efficace. Le deuxième permet d’éviter que cette efficacité n’entraîne des dépenses inutiles, un accès incontrôlé ou des dépendances envers des fournisseurs que l’entreprise n’a jamais délibérément acceptées.