Du modèle au produit

Ce que l'IA fait bien ici, ce qu'elle fait mal

Ce qu'elle fait bien

• Changer de modèle sans refaire le produit: quand l'API isole le modèle, l'équipe en change sans toucher à l'écran.
• Servir plusieurs produits: un même modèle alimente un assistant RH, une recherche documentaire et un logiciel de gestion de la relation client (CRM).
• Proposer dans l'écran de travail: la suggestion intégrée au logiciel métier arrive au moment où l'utilisateur décide.

Ce qu'elle fait mal

• Connaître vos documents: le modèle ignore le règlement interne tant que le produit ne le lui transmet pas.
• Agir dans vos systèmes: sans intégration, sa réponse reste un texte que quelqu'un recopie.
• Appliquer vos règles d'usage: les droits d'accès et les interdits se programment dans le produit.
• Porter la décision: le modèle propose une sortie sans en mesurer l'effet sur le client.
• Répondre vite à l'heure de pointe: le temps de réponse dépend de la capacité de calcul que le fournisseur réserve.
• Corriger un besoin mal posé: un modèle performant sur la mauvaise tâche ne réduit aucun délai du métier.

Les éléments d'un système d'IA

Un système d'IA réunit cinq éléments. Le besoin nomme une tâche et le résultat attendu. Les données fournissent les exemples, les documents ou les signaux disponibles. Le modèle est une fonction apprise qui transforme une entrée en sortie. Le produit l'entoure d'une interface, d'outils, de règles et d'intégrations. La décision humaine vient en dernier: une personne vérifie la sortie, l'accepte, la corrige ou la refuse.

Qu'est-ce que l'IA? suit une demande à travers un système: l'entrée, la transformation, la sortie, la décision. Les cinq éléments décrivent ce qui doit être en place avant la première demande. Les données sont les documents et les exemples que le produit met à la disposition du modèle. L'entrée est la question qu'un utilisateur pose.

Le service du personnel d'une administration cantonale reçoit chaque semaine les mêmes questions sur les vacances, le congé paternité et les heures supplémentaires. Le besoin: répondre à un collaborateur en moins d'une minute avec l'article applicable. Les données: le règlement du personnel, les directives internes et les réponses déjà données. Le modèle: un modèle de langage qui rédige la réponse. Le produit: une fenêtre dans l'intranet, une recherche dans les directives, la règle «citer l'article» et un accès réservé aux collaborateurs connectés. La décision: le collaborateur lit l'article cité. Le service du personnel tranche les cas que le règlement ne couvre pas.

Retirez un élément et le résultat change. Sans les directives, le modèle répond avec le droit du travail en général. Sans la règle «citer l'article», le collaborateur n'a rien à vérifier. Sans la reprise par le service du personnel, un cas limite reçoit une réponse aussi assurée qu'un cas simple. L'évaluation des données disponibles dit, avant tout choix de modèle, si le deuxième élément existe. Pour transmettre les directives au modèle au moment de la question, voyez la génération augmentée par la recherche (RAG).

Un modèle dans plusieurs systèmes

La norme ISO/IEC 22989 définit le système d'IA comme un système technique qui produit des contenus, des prévisions, des recommandations ou des décisions pour des objectifs que des humains ont fixés. Le besoin fait donc partie de la définition.

Le règlement européen sur l'IA (AI Act) sépare les deux objets. Son article 3 définit le système d'IA, dont les sorties peuvent influencer un environnement physique ou virtuel, et le modèle d'IA à usage général, qui s'intègre dans des systèmes divers. Son considérant 97 précise qu'un modèle ne forme pas à lui seul un système: il lui faut d'autres composants comme une interface utilisateur. Les classes de risque des systèmes portent sur l'usage prévu. Le fournisseur d'un modèle à usage général a ses propres obligations (art. 53 à 55). Un outil qui trie des candidatures intègre un modèle et devient un système à haut risque (annexe III, point 4). Un assistant RH qui répond aux questions sur le règlement intègre le même modèle et doit informer l'utilisateur qu'il échange avec une IA (art. 50). Un correcteur orthographique qui l'intègre n'a aucune obligation particulière. Le règlement s'applique à une entreprise suisse qui met un système sur le marché ou en service dans l'Union. Il s'applique aussi quand les sorties de son système sont utilisées dans l'Union (art. 2).

Sculley et al. (NeurIPS 2015) font le même constat en ingénierie: dans un système de machine learning réel, le code du modèle n'occupe qu'une petite fraction de l'ensemble. La collecte et la vérification des données, la configuration, la surveillance et l'infrastructure de service l'entourent. La dette technique s'accumule au niveau du système.

Une démonstration montre le modèle. Un projet livre le système. Devant une démonstration réussie, l'analyste demande ce qui manque encore: quelles données, quelle interface, quelles règles, qui décide.

Du problème métier au produit

Le même système se lit aussi depuis le problème métier en cinq étapes. Le problème décrit ce qui ne va pas pour le métier. La tâche nomme ce qu'une personne doit accomplir pour le résoudre. La capacité nomme ce que le système doit savoir faire pour l'aider. La fonctionnalité place cette capacité dans un écran. Le produit assemble la capacité, l'interface et les règles d'usage en un outil qu'une équipe utilise.

Sur la hotline d'une caisse maladie, les assurés attendent trop longtemps au téléphone. Pour résoudre ce problème, le conseiller doit retrouver le dossier et la réponse pendant l'appel. Pour l'aider dans cette tâche, le système recherche l'information dans les dossiers et les directives de remboursement. Cette capacité prend la forme d'une recherche et d'une suggestion de réponse dans l'écran du conseiller. Le portail de service de l'équipe réunit ces fonctionnalités en un produit.

Les cinq étapes disent comment de gauche à droite et pourquoi de droite à gauche: chaque fonctionnalité se justifie par une tâche que le problème justifie à son tour. Une fonctionnalité qu'aucune tâche ne réclame sort du périmètre. Des cinq étapes, seule la capacité fait appel à l'IA. Une recherche plein texte bien réglée la fournit parfois. Pour décider si l'IA est nécessaire, voyez quand une règle suffit. Le People + AI Guidebook de Google part aussi du problème: l'équipe identifie le bon problème avant tout travail technique. Selon ce guide, une solution plus simple se construit, s'explique et se maintient plus facilement.

En atelier, l'analyste précise dans quel sens il emploie le mot «capacité».

Pour décrire un cas d'usage champ par champ et le comparer à d'autres, voyez l'identification et la priorisation des cas d'usage. Pour choisir comment obtenir la capacité, voyez développer, acheter ou configurer.

Quatre couches à ne pas confondre

Le logiciel métier est ce que l'utilisateur voit et utilise. L'API ou le service relie l'application au modèle. Une API (Application Programming Interface) est le point d'accès par lequel un logiciel en appelle un autre. L'infrastructure fournit les machines, le stockage et le calcul.

Dans le CRM d'une PME romande, un commercial clique sur «proposer une relance». L'API transmet au modèle l'historique du client et la consigne de rédaction. Le modèle propose un texte. L'infrastructure exécute le calcul sur des serveurs dont le lieu dépend du fournisseur.

Quand le résultat déçoit, la cause se situe dans l'une des couches. La correction change avec la couche. Changer de modèle ne répare pas une API qui omet le dernier échange.

La troisième ligne montre qu'une plainte n'indique pas toujours sa couche. Une remise inventée par le modèle et une remise absente des données transmises produisent la même phrase fausse. Avant d'accuser le modèle, l'équipe relit dans le journal de l'API les données transmises. Si le catalogue y figurait, le modèle a inventé: les hallucinations expliquent pourquoi. La quatrième ligne repose sur le même journal: l'équipe soumet l'entrée enregistrée à un autre modèle. Seule la couche du modèle change.

Où se place la décision humaine

Le produit fixe la décision humaine: qui voit la sortie, à quel moment, avec quels moyens de la corriger. Dans le CRM, le commercial relit la relance avant l'envoi. Un produit qui envoie la relance sans ce passage a supprimé le cinquième élément du système.

Pour une entreprise privée ou un organe fédéral, la loi fédérale sur la protection des données (LPD) fixe un plancher. Une administration cantonale applique la loi cantonale sur la protection des données. Le responsable du traitement informe la personne concernée de toute décision prise exclusivement sur la base d'un traitement automatisé qui produit des effets juridiques pour elle ou l'affecte de manière significative (LPD, art. 21). Sur demande, la personne fait valoir son point de vue et obtient qu'une personne physique revoie la décision. Ces deux obligations tombent si la décision, liée à la conclusion ou à l'exécution d'un contrat, fait droit à la demande de la personne ou si celle-ci a consenti expressément à la décision automatisée. Pour un système que l'AI Act classe à haut risque, l'article 14 exige en plus un contrôle humain: le système est conçu pour que la personne désignée puisse comprendre ses capacités et ses limites et détecter les anomalies. Hors de cette classe et au-dessus du plancher de la LPD, le partage des rôles reste un choix de conception. Pour fixer ce partage cas par cas, voyez l'humain dans la boucle.

Vérifier le résultat

L'analyste passe cette liste sur une proposition de solution d'IA ou sur une démonstration.

• Le besoin nomme-t-il une tâche et le résultat attendu?
• La proposition identifie-t-elle les données que le modèle recevra et leur source?
• La proposition distingue-t-elle le modèle du produit qui l'entoure?
• Le produit nomme-t-il son interface, ses intégrations et ses règles d'usage?
• Une personne désignée accepte-t-elle, corrige-t-elle ou refuse-t-elle chaque sortie avant qu'elle produise un effet?
• Chaque fonctionnalité se rattache-t-elle à une tâche?
• Chaque tâche se rattache-t-elle au problème métier?
• La démonstration a-t-elle tourné dans le logiciel métier sur vos données?
• L'équipe rattache-t-elle chaque plainte des utilisateurs à l'une des quatre couches?
• Le pays où l'infrastructure traite les données est-il connu?
• Ce pays figure-t-il à l'annexe 1 de l'ordonnance sur la protection des données (OPDo)?
• Le contrat prévoit-il des garanties (LPD, art. 16) pour un pays absent de l'annexe 1?
• Si l'annexe 1 pose une condition pour ce pays, le fournisseur la remplit-il? Pour les États-Unis, cette condition est une certification.

Techniques liées

• Cadrage et recadrage du problème: énoncer le problème métier avant toute tâche ou capacité.
• Décomposition fonctionnelle: descendre du problème à la tâche, puis à la fonctionnalité.
• Analyse des capacités métier: la capacité au sens du BABOK désigne ce que l'organisation sait faire.
• Analyse des interfaces: spécifier ce que l'API transmet au modèle et ce qu'elle en reçoit.
• Analyse des exigences non fonctionnelles: chiffrer le temps de réponse, la disponibilité et le lieu de traitement que l'infrastructure doit tenir.