,

Comprendre le risque lors de la création d’une étude d’opportunité pour l’IA générative

L’intelligence artificielle générative se trouve à un carrefour intéressant. Au cours des deux dernières années, les TI d’entreprise ont considérablement changé, et l’IA en est l’une des raisons majeures. Cette technologie est puissante, mais il a fallu du temps pour comprendre comment la gérer et la rendre performante de manière fiable au sein de véritables organisations, au service de résultats concrets.

Nous dépassons maintenant la phase la plus intense du cycle de l’engouement (hype cycle). Les discussions délaissent les scénarios de science-fiction dystopiques pour se tourner vers des applications pratiques et concrètes. C’est à ce moment précis que l’IA cesse d’être une simple démonstration pour devenir une capacité prête pour la production.

C’est également le moment où vous devez bâtir une étude d’opportunité (business case) solide. Pour y parvenir, vous devez avoir une vision claire des avantages attendus, des coûts, des risques et des échéanciers.

Si vous tentez de déployer l’IA dans l’ensemble d’une organisation, la question difficile n’est pas de savoir si vous pouvez l’utiliser, mais plutôt si vous devriez le faire. Grâce à une expérience concrète accrue, nous pouvons désormais mieux distinguer les signaux faibles du bruit de fond. Vous trouverez ci-dessous les éléments clés à prendre en compte lors de l’évaluation des cas d’utilisation de l’IA générative sur des plateformes telles que ServiceNow et Salesforce.

1) Le risque d’hallucination, les erreurs catastrophiques et le biais de survie

L’une des grandes différences entre les humains et l’IA réside dans leur façon de gérer le risque.

Les humains sont sujets à l’erreur, mais la plupart du temps, nous évitons d’instinct les décisions comportant des risques catastrophiques, même lorsque la probabilité d’échec est faible. Nous faisons cela de manière presque inconsciente.

Dans les écosystèmes ServiceNow et Salesforce, les équipes ne déploient généralement pas de code en production sans approbations, tests et validations. Nous ne créons pas de nouvelle table de données sans une révision de la sécurité. Ce n’est pas parce qu’il est impossible de contourner ces contrôles, mais bien parce que les conséquences négatives sont inacceptables (rendre une application de production indisponible est une décision qui peut mettre fin à une carrière).

L’IA générative ne possède pas ce filtre de risque intégré. Elle peut échouer sur des tâches triviales comme sur des tâches à enjeux élevés, et ce, avec le même ton d’assurance. C’est pourquoi les mises en garde se multiplient dans le monde des affaires : des rapports hallucinés qui nuisent à la réputation, des agents d’IA qui suppriment ou corrompent des données de production, et des robots conversationnels qui fournissent avec aplomb des conseils menant à des décisions gravement préjudiciables.

Tout cas d’utilisation comportant des risques graves exige, au minimum, une supervision humaine pour assurer la révision et la responsabilité. Ce n’est pas parce que les humains sont plus intelligents, mais parce que des humains responsables ont tendance à éviter les résultats catastrophiques. Lorsque le risque est élevé, ce comportement est une fonctionnalité essentielle, et non une anomalie.

2) La spirale de la dette technique alimentée par les jetons (tokens)

Les outils d’aide au développement basés sur les grands modèles de langage (LLM) transforment la façon dont les logiciels sont conçus. Cependant, cette autonomie accrue s’accompagne d’un risque réel : l’augmentation de la dette technique et la hausse du coût des jetons à mesure que les bases de code prennent de l’expansion.

Cela se produit pour plusieurs raisons :

  • Des outils de codage autonomes non surveillés peuvent introduire du code superflu qui passe l’étape de révision, mais qui n’apporte que très peu de valeur ajoutée.
  • À mesure que le volume de code augmente, il devient plus difficile pour les humains de le comprendre, de le gouverner et de le maintenir.
  • Lorsque la maintenabilité diminue, les équipes s’en remettent encore plus aux outils d’IA pour restructurer (refactor) et nettoyer l’environnement, ce qui génère encore plus d’instabilité et de code.

À mesure que les systèmes se développent, la quantité d’analyses, de recherches de données et de contexte requise pour travailler en toute sécurité croît de façon exponentielle. Cela se traduit par une complexité accrue du code, des bases de code plus volumineuses et une consommation de jetons de plus en plus élevée.

Pour atténuer ce risque, il faut traiter le code généré par l’IA comme n’importe quelle autre base de code : le maintenir compréhensible, imposer des normes, exiger des tests et limiter l’autonomie de l’outil. Dans ServiceNow, l’IA peut rédiger un script ou un flux de travail complet, mais celui-ci ne devrait jamais être mis en production à moins qu’une personne ne comprenne chaque ligne de code. Dans ce paradigme, le rôle du développeur passe de la saisie de code à la recherche rigoureuse de clarté, d’exactitude et de simplicité, au service des résultats d’affaires.

3) La concentration des fournisseurs et la dépendance institutionnelle

Un autre risque sous-estimé est la dépendance envers un nombre restreint de fournisseurs d’IA et, au fil du temps, la dépendance envers l’automatisation pour les processus d’affaires essentiels.

Si les organisations ne sont pas vigilantes, elles risquent de se retrouver prisonnières d’un fournisseur de modèles tout en subissant une atrophie de leurs connaissances institutionnelles : de moins en moins de personnes comprennent comment les flux de travail fonctionnent réellement parce que leur exécution a été externalisée vers une automatisation propulsée par l’IA.

Lorsque cela se produit, les organisations se retrouvent en position de faiblesse pour négocier si les fournisseurs modifient leurs tarifs, les conditions de leurs contrats ou l’orientation de leurs produits.

L’écosystème évolue rapidement : les modèles en code libre (open-source), les modèles exécutés localement et les plateformes d’entreprise s’améliorent d’année en année. L’objectif n’est pas d’éviter les fournisseurs, mais de faire de la dépendance un choix de conception conscient, et non un accident.

4) Les hypothèses relatives à la confidentialité et à la sécurité

Selon le fournisseur et la configuration choisis, les requêtes (prompts) et les résultats de l’IA générative peuvent être enregistrés, conservés ou utilisés pour améliorer les modèles. Même lorsque l’IA générative est intégrée à une plateforme d’entreprise, un fournisseur de modèles tiers peut tout de même être impliqué.

Ne présumez de rien – vérifiez :

  • Quelles données quittent votre environnement
  • Ce qui est conservé (et pour combien de temps)
  • Qui peut accéder aux journaux d’activité (logs)
  • Ce que permettent les conditions contractuelles

Pour les cas d’utilisation sensibles, envisagez des déploiements dédiés, des contrôles de conservation plus stricts ou des modèles exécutés localement, en particulier lorsque les exigences de classification des données sont rigoureuses.

5) Vulnérabilité et exploitation des modèles

Les grands modèles de langage sont des logiciels. Comme tout logiciel, ils peuvent être exploités.

Les recherches démontrent qu’un nombre étonnamment restreint de documents malveillants peut créer des vulnérabilités de type porte dérobée (backdoor). Même si cela semble peu probable, il vaut la peine d’en tenir compte lors de la conception de solutions. Pour les flux de travail d’entreprise, cela implique des autorisations d’outils strictes, des garde-fous basés sur les rôles, des contrôles d’accès robustes et une surveillance active des comportements suspects.

Une règle simple : ne laissez jamais le modèle accéder à ce que l’utilisateur n’est pas autorisé à voir.

Le pire des scénarios n’est pas d’obtenir une mauvaise réponse. C’est de voir un assistant transformé en menace informatique agir à travers l’ensemble des systèmes de l’entreprise.

En conclusion : un levier discipliné plutôt que de l’engouement

L’IA transforme la façon dont le travail s’effectue. Plutôt que de tenter d’intégrer l’IA partout, les organisations qui s’imposeront seront celles qui choisiront les bons cas d’utilisation, limiteront les modes de défaillance, mesureront les résultats et mettront en place la gouvernance nécessaire pour transformer la nouveauté en habitude.

Voilà ce que signifie réellement l’adoption de l’IA. Ce n’est pas une question d’engouement passager. Ce n’est pas une question de peur. C’est l’utilisation disciplinée d’un outil puissant, employé exactement là où il convient, et évité là où il n’a pas sa place.