Une fonctionnalité qui passait tous les tests en mars se comporte différemment en septembre. Personne n’a touché au code. Les invites sont les mêmes, la recherche documentaire est la même, et la suite de tests qui était au vert en mars l’est toujours. Quelque chose a bougé en amont, et le premier signal fiable a été la remarque d’un client.

C’est la condition ordinaire de l’exploitation d’une IA dans un produit, pas une panne exotique. Presque toute organisation qui s’appuie sur un modèle de fondation exploite une dépendance qu’elle ne contrôle pas, qu’elle ne peut pas geler indéfiniment et qu’elle n’a pas spécifiée. C’est tenable. Ce n’est tenable que délibérément.

Le risque qui croît plus vite que l’adoption

Selon Eurostat : utilisation de l’intelligence artificielle dans les entreprises, environ 20 % des entreprises de l’UE d’au moins dix salariés utilisaient des technologies d’IA en 2025, contre 13,5 % l’année précédente, et 55 % parmi les grandes entreprises. Le Stanford HAI AI Index Report 2026 recense pour sa part 362 incidents d’IA documentés en 2025, contre 233 l’année précédente.

Le déploiement devance la pratique d’exploitation. Et la partie la moins visible de cette pratique est la gestion d’une dépendance qui change sans que vous n’y soyez pour rien.

Le législateur européen traite désormais explicitement cette catégorie de dépendance. Le règlement (UE) 2022/2554 (DORA) impose aux entités financières de recenser leurs prestataires TIC tiers, de les encadrer contractuellement et de prévoir des stratégies de sortie. Hors du secteur financier, la liste de contrôle reste utile : qui dépend de quoi, que se passe-t-il en cas de défaillance, et est-ce couvert par le contrat ?

Six pratiques qui maintiennent une fonctionnalité fiable

1. Figer la version, et savoir combien de temps cela tiendra

Appeler le point de terminaison par défaut d’un fournisseur, c’est accepter ce qui se trouve derrière un matin donné. Nommer une version précise transforme un changement invisible en changement planifié. Le figeage n’est pas toute la réponse, car les versions sont retirées. Le chiffre à connaître n’est donc pas seulement la version que vous utilisez, mais le préavis que le fournisseur accorde avant le retrait — et la durée de votre cycle d’évaluation et de validation. Si le second dépasse le premier, cet écart est le risque réel, et il relève des achats plutôt que de l’ingénierie.

2. Tenir un jeu d’évaluation représentatif de votre travail

Les référentiels publics décrivent une capacité générale. Ils ne disent rien sur la capacité du modèle à traiter encore vos formats de documents, vos noms de produits, vos cas limites et votre vocabulaire réglementaire. Un jeu d’évaluation utile provient de travail réel, est annoté par des personnes qui savent reconnaître une bonne réponse, est figé pour que les résultats restent comparables dans le temps, et est pondéré vers les cas qui font vraiment mal : les ambigus, ceux où l’information manque, et ceux où la bonne réponse est de refuser.

Cent cas bien choisis valent mieux que dix mille cas ramassés. Le coût est dans l’annotation, et il se paie une fois.

3. Traiter une montée de version comme une livraison, pas comme une notification

L’arrivée d’une nouvelle version n’est pas un événement qui vous arrive, c’est un changement que vous acceptez. Passez le jeu d’évaluation sur la version candidate, comparez avec la version figée, examinez les écarts cas par cas et non seulement le score agrégé, puis décidez. Une parité en moyenne masque régulièrement une catégorie devenue nettement moins bonne : la moyenne tient parce qu’autre chose s’est amélioré.

Le NIST AI Risk Management Framework décrit cela comme une activité continue sur le cycle de vie plutôt qu’une qualification unique. Concrètement : un point de passage dont quelqu’un répond, et qu’il peut refuser d’ouvrir.

4. Instrumenter la sortie, pas seulement la disponibilité

La supervision classique indique que le service a répondu. Elle n’indique pas que les réponses sont devenues moins utiles. Ajoutez des signaux de fond : taux de refus et de repli, distribution de la longueur des réponses, proportion de réponses citant une source là où c’est exigé, taux de correction humaine, et taux d’abandon du parcours. Aucun n’est une mesure de qualité à lui seul, mais ensemble ils bougent avant les réclamations. Un changement de distribution mérite d’être examiné même quand chaque réponse prise isolément paraît raisonnable.

5. Prévoir un repli qui ne soit pas le même modèle

La résilience, c’est que la fonctionnalité se dégrade au lieu de disparaître. Selon la charge, ce peut être un second fournisseur, un modèle plus petit hébergé en interne, un chemin déterministe à base de règles, une réponse en cache, ou un message honnête qui oriente vers une personne. L’essentiel est que le repli soit exercé selon un calendrier. Un repli jamais testé est une croyance, pas un contrôle, et il échoue en général le jour où l’on en a réellement besoin.

6. Inscrire les droits d’évaluation dans le contrat

Une bonne part de tout cela n’est pas disponible si elle n’a pas été achetée. Préavis avant le retrait d’une version, droit d’évaluer une version candidate avant qu’elle ne devienne la version par défaut, information sur les changements significatifs de comportement, traitement et conservation des données, continuité de service et assistance à la réversibilité : tout cela appartient au contrat. Un bon tarif de pilote est une mauvaise affaire si l’organisation ne peut ensuite ni tester, ni exploiter, ni remplacer le service.

Qui en répond

Ces pratiques échouent en silence quand personne n’en répond, car aucune n’est urgente un jour donné. La norme de système de management de l’IA ISO/IEC 42001 offre un cadre qu’on peut emprunter sans se faire certifier : responsabilités définies, objectifs documentés, changement maîtrisé et revue dans la durée.

Transposé à une équipe produit, cela fait quatre responsabilités nommées. Quelqu’un répond du jeu d’évaluation et le maintient à jour. Quelqu’un répond de la décision de montée de version et peut dire non. Quelqu’un répond des signaux en production et les regarde à un rythme fixe. Quelqu’un répond de la relation fournisseur et des clauses du contrat. Ce peut être quatre casquettes sur deux têtes. Ce ne peut pas être personne.

Par où commencer

Si rien de tout cela n’existe encore, la première semaine n’est pas un exercice d’architecture. Écrivez quels modèles le produit appelle, dans quelles versions, via quels comptes. Prenez cinquante cas réels du mois écoulé et faites annoter la sortie correcte. Passez-les sur ce qui tourne aujourd’hui et conservez le résultat. C’est une mesure de référence, et cela prend une semaine.

Tout le reste devient plus simple ensuite, parce que chaque question ultérieure — cette montée de version a-t-elle aidé, ce changement d’invite a-t-il fonctionné, la fonctionnalité se dégrade-t-elle — devient une comparaison plutôt qu’une discussion d’opinion.

Si vous intégrez une fonctionnalité d’IA dans un produit et souhaitez concevoir la pratique d’exploitation en même temps : c’est du travail produit et plateforme, généralement cadré comme un sprint de mise en œuvre.

Cet article est une adaptation de l’original anglais. En cas de divergence, la version anglaise fait foi.