L’IA partout : quand les étiquettes sont plus absurdes que les fonctionnalités

Quand les étiquettes dépassent les fonctionnalités

« IA » signifiait autrefois que vous aviez un modèle : vous l’entraîniez, le déployiez, et passiez l’année suivante à apprendre ce qu’est la dérive lors des rotations d’astreinte. Aujourd’hui « IA » peut signifier n’importe lequel de ces éléments :

• Un moteur de règles codé en dur avec une nouvelle phrase marketing.
• Un appel API fournisseur où vous ne contrôlez ni le comportement du modèle, ni la rétention des données, ni le rythme des releases.
• Un modèle hébergé localement avec une facture GPU et un problème de mise en file d’attente.
• Une fonctionnalité qui était déterministe et qui affiche désormais un score de confiance et un haussement d’épaules.

Les étiquettes comptent parce qu’elles modifient la prise de décision. Une fois qu’on tague quelque chose « IA », les équipes acceptent des modes de défaillance qu’elles n’accepteraient jamais ailleurs : non-déterminisme, exactitude partielle, régressions soudaines liées à des changements en amont, et des sorties difficiles à expliquer aux auditeurs ou aux clients.

Et « IA partout » tend à créer une pathologie organisationnelle spécifique : vous arrêtez de demander ce que fait la fonctionnalité et vous commencez à demander ce que l’étiquette vous apporte. C’est ainsi que naissent les grille-pain « compatibles IA ». Ou, plus couramment, des routages de tickets « activés par IA » qui coûtent plus cher que les humains remplacés et qui routent plus mal quand ça compte.

Voici la posture opérationnelle qui vous garde employable : traitez « IA » comme un détail d’implémentation, pas comme une catégorie produit. Exigez la même rigueur que pour toute dépendance critique : SLOs explicites, critères d’acceptation testables, plans de rollback, plafonds de coût et contrôles de sécurité.

Une citation à garder sur soi, parce qu’elle reste vraie : « L’espoir n’est pas une stratégie. » — Rick Page.

Pourquoi l’étiquette est dangereuse

Elle est dangereuse parce qu’elle invite à la prestidigitation verbale. Dès que quelqu’un dit « le modèle s’en chargera », vous devriez entendre : « nous n’avons pas spécifié les exigences et nous externalisons notre réflexion à la probabilité. » Cela peut convenir pour l’autocomplétion. Ce n’est pas acceptable pour un pipeline de facturation.

La plupart des « fonctionnalités IA » échouent pour des raisons ennuyeuses :

• Elles sont plus lentes que le flux existant, donc les utilisateurs les abandonnent.
• Elles sont instables sous charge, donc les équipes de support apprennent à les désactiver.
• Elles sont coûteuses à l’échelle, donc les finances deviennent votre déclencheur d’incident.
• Elles sont dangereuses dans les cas limites, donc le juridique vous fait entourer le tout de disclaimers jusqu’à les rendre inutiles.

Blague #1 : On l’appelait « propulsé par l’IA » jusqu’au premier incident, où c’est devenu « temporairement basé sur des règles pour la stabilité ».

Ce que signifie une « vraie fonctionnalité » en production

Une vraie fonctionnalité a :

• Des entrées que vous pouvez énumérer et valider.
• Des sorties que vous pouvez scorer, borner et expliquer.
• Des performances que vous pouvez prédire sous charge.
• Des solutions de secours qui préservent le parcours utilisateur.
• De la télémétrie qui vous dit si elle aide ou nuit.

« IA » n’annule pas ces besoins. Elle les multiplie. Vous avez maintenant un composant stochastique dont les modes de défaillance peuvent être subtils : il renvoie quelque chose, mais pas quelque chose d’utile, et il le fait avec assurance. Ce n’est pas un 500. C’est une corruption silencieuse des données en langage humain.

Faits et contexte historique pertinents pour les opérations

Beaucoup traitent le moment « IA partout » comme sans précédent. Ce n’est pas le cas. La technologie est relativement nouvelle ; la bulle médiatique est classique. Quelques faits concrets aident à argumenter avec assurance dans des réunions où l’on préfère les slogans :

1. Le terme « intelligence artificielle » a été inventé en 1956 lors de l’atelier de Dartmouth. Le branding était ambitieux dès le départ, bien avant que des systèmes de production existent pour le juger.
2. L’IA a connu plusieurs « hivers » (notamment dans les années 1970 et à la fin des années 1980/début 1990) lorsque les financements se sont effondrés après des promesses gonflées. Le battage est cyclique ; la dette opérationnelle est permanente.
3. Les systèmes experts ont dominé l’IA d’entreprise dans les années 1980 : règles, bases de connaissances et maintenance fragile. Le « prompt engineering comme logique métier » d’aujourd’hui est étrangement similaire — juste avec plus de tokens et moins de garanties.
4. La renaissance moderne de la rétropropagation en 1986 (Rumelhart, Hinton, Williams) rappelle que des percées peuvent rester en sommeil jusqu’à ce que le calcul et les données les rendent pratiques. La praticabilité est une contrainte opérationnelle, pas philosophique.
5. Le moment ImageNet (2012) (le deep learning surpassant les méthodes précédentes en vision) portait autant sur les GPU et les jeux de données que sur les algorithmes. Votre « fonctionnalité IA » est probablement une histoire de chaîne d’approvisionnement : puces, bande passante, stockage et disponibilité du fournisseur.
6. Les Transformers (2017) ont rendu les grands modèles de langage évolutifs, mais ont aussi fait de l’inférence un enjeu produit de premier ordre pour le coût et la latence. Si vous ne pouvez pas vous permettre le p99, vous n’avez pas une fonctionnalité.
7. La performance des modèles n’est pas monotone dans le temps. Les modèles déployés peuvent se dégrader au fil des changements de comportement utilisateur, des évolutions linguistiques, de la saisonnalité ou de la dérive des pipelines de données en amont. Le logiciel traditionnel ne pourrit pas souvent de cette façon.
8. La réglementation « IA » s’accélère dans plusieurs juridictions, ce qui signifie que la provenance, l’explicabilité et les traces d’audit ne sont plus des « extras entreprise » ; ce sont des exigences de base dans des environnements à gestion des risques.

Un cadre décisionnel : quoi livrer, quoi interdire, quoi mesurer

Commencez par la seule question qui compte : quel problème résolvons-nous ?

Pas « comment ajoutons-nous de l’IA ». L’énoncé du problème doit être lisible sans les lettres A et I. Exemple :

• Bon : « Réduire le temps moyen de résolution en résumant les timelines d’incident depuis les logs et tickets. »
• Mauvais : « Ajouter un assistant IA au NOC. »

Si vous ne pouvez pas écrire des critères de succès sous forme de test, vous êtes sur le point de livrer une démo. Les démos sont acceptables. Elles doivent vivre dans des sandboxes avec des interrupteurs d’arrêt nets.

Définissez votre classe de fonctionnalité : déterministe, probabiliste ou consultative

La plupart des incidents en production surviennent parce que des équipes déploient un système probabiliste comme s’il était déterministe. Décidez ce que vous construisez :

• Fonctionnalité déterministe : la même entrée produit la même sortie. Vous pouvez mettre en cache. Vous pouvez raisonner dessus. Parfait.
• Fonctionnalité probabiliste : les sorties varient, la confiance compte et la justesse est statistique. Nécessite scoring, monitoring et garde-fous.
• Fonctionnalité consultative : le système suggère ; un humain ou une porte déterministe décide. C’est là que la plupart des « IA partout » devraient rester tant que la sécurité n’est pas prouvée.

Rendez-le mesurable : livrez avec une « métrique d’impact » et une « métrique de dommage »

Les métriques d’impact répondent à « est-ce que ça aide ? » Les métriques de dommage répondent à « qu’est-ce qui casse quand c’est mauvais ? » Vous avez besoin des deux.

• Exemples d’impact : taux de déviation (support), temps de complétion (workflow), hausse de conversion (commerce), temps économisé par ticket (ops).
• Exemples de dommage : remboursements incorrects, tickets haute gravité mal routés, violations de politique, fuite de PII, churn client déclenché par des réponses absurdes.

Puis ajoutez des contraintes :

• Budget de latence : objectifs p50/p95/p99.
• Budget d’erreur : seuils de disponibilité et de correction.
• Budget de coût : coût par requête et plafond mensuel avec alertes.

Architectez pour la défaillance, pas pour les impressions

« IA partout » signifie souvent « nouvelle dépendance réseau partout ». C’est ainsi que vous obtenez des défaillances en cascade. Traitez le composant IA comme un upstream instable :

• Timeouts avec des valeurs sensées (plus courts que vous ne le pensez).
• Disjoncteurs pour réduire la charge.
• Mode de secours qui préserve la fonctionnalité principale.
• Compartimentage : isolez la fonctionnalité IA pour qu’elle ne prive pas le reste du système.
• Requêtes rejouables pour évaluation hors-ligne et analyse post-incident.

Blague #2 : Notre « feuille de route IA » était tellement aggressive que nous avons dû ajouter un nouveau niveau à la taxonomie des incidents : « Sev-2, mais philosophique ».

Ne confondez pas « intelligent » et « fiable »

Les équipes aiment le brillant. Les utilisateurs aiment la fiabilité. Les dirigeants aiment les chiffres trimestriels. Votre travail est de livrer les trois en mettant la fiabilité avant la nouveauté. La manière la plus simple : exigez que chaque fonctionnalité IA ait un fallback non-IA qui respecte l’UX minimum. Si le fallback est humiliant, tant mieux — vous savez alors ce que « minimum » signifie vraiment.

Trois mini-récits d’entreprise depuis les tranchées

Mini-récit n°1 : L’incident causé par une mauvaise hypothèse

Dans une entreprise B2B SaaS de taille moyenne, la direction du support voulait un « triage de tickets IA ». Le pitch était simple : ingérer les emails entrants, classifier l’intention, router vers la bonne file, auto-taguer la priorité, réduire le temps de réponse. La démo du fournisseur avait fière allure. L’intégration est passée en production derrière un feature flag. Tout le monde s’est félicité d’être moderne.

L’hypothèse erronée était subtile : l’équipe supposait que la classification du modèle était « comme un moteur de règles, mais plus intelligent ». Autrement dit, stable. Ils n’ont pas construit de monitoring explicite de dérive ni de fallbacks robustes parce que la fonctionnalité n’était pas « sur le chemin critique »… jusqu’à ce qu’elle devienne silencieusement critique. Les agents de support ont arrêté de trier manuellement parce que le nouveau système était plus rapide, et les managers ont commencé à les mesurer en supposant que le routage était correct.

Puis un lancement produit a changé le langage des clients. Les gens ont commencé à utiliser de nouveaux termes proches des anciens mais pas identiques. Le modèle a commencé à router « contestation de facturation » vers « demande de fonctionnalité ». Le premier symptôme n’était pas un 500 ; c’était un client ayant reçu une réponse enthousiaste sur la feuille de route produit à la place d’une demande de remboursement. Le client a escaladé. Puis d’autres ont fait de même.

Les opérations sont intervenues après coup. Les logs montraient que le système était « sain ». Latence ok. Taux d’erreur ok. L’incident était une dégradation de la correction. Une fois qu’ils ont échantillonné les mauvais routages, l’échec est devenu évident, mais cela a pris des jours parce qu’il n’y avait pas de boucle de feedback « vérité terrain » ni de comparaison de référence. La correction n’était pas glamour : forcer les agents à confirmer le routage (mode consultatif), stocker les résultats labellisés, réentraîner et évaluer chaque semaine, et ajouter des alarmes de dérive basées sur les changements de distribution de labels.

La vraie leçon : les systèmes probabilistes ont besoin de télémétrie explicite de correction. « Aucun erreur dans les logs » est dénué de sens quand le système se trompe poliment.

Mini-récit n°2 : L’optimisation qui s’est retournée contre eux

Une plateforme retail a ajouté un « amélioreur de description produit » basé sur un LLM. Il prenait le texte fournisseur et l’homogénéisait pour la cohérence. La première version tournait en asynchrone et écrivait les résultats dans un cache. C’était lent mais sûr : si le job échouait, le texte ancien restait. Puis le marketing a voulu l’avoir « en temps réel » dans l’éditeur produit pour que les humains voient la magie.

Le plan d’optimisation semblait raisonnable : mettre en cache les prompts et réutiliser les résultats ; augmenter la concurrence ; réduire les timeouts pour que l’UI ne bloque pas. Ils ont aussi ajouté un second modèle en fallback. Ils ont mesuré le p50 et déclaré victoire.

Ce qu’ils ont oublié, c’était le p99 pendant les pics d’utilisation de l’éditeur. Quand la concurrence a monté, l’API en amont a commencé à appliquer des limites de débit. Le système a plongé dans les retries. Les retries ont amplifié la charge. Le modèle de secours est intervenu et a renvoyé des styles différents. Les utilisateurs ont commencé à sauvegarder des brouillons au ton incohérent et, pire, avec des spécifications parfois hallucinées. Le système n’était pas « down », il était « erratique ».

Les coûts ont explosé parce que la tempête de retries a augmenté l’utilisation de tokens. Les finances s’en sont aperçues avant l’ingénierie. Le retour de bâton était parfait : pire UX, coût plus élevé et backlog support parce que les fournisseurs se plaignaient des modifications incorrectes.

La correction a été de la discipline SRE classique : limiter la concurrence, implémenter des backoffs exponentiels avec jitter et budgets de retry stricts, revenir à la génération asynchrone avec une UX « brouillon prêt » explicite, et ajouter une couche de validation qui vérifie les sorties par rapport aux attributs produits structurés (dimensions, matériaux) avant acceptation. Ils ont aussi commencé à monitorer les réponses de rate-limit comme SLI de première classe.

Mini-récit n°3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une équipe de services financiers a déployé un « assistant IA » interne pour les analystes. Il répondait aux questions en s’appuyant sur un système de récupération (retrieval) sur les politiques et rapports antérieurs. La revue des risques initiale a été tendue : fuite de données, hallucinations, conformité. L’équipe a fait quelque chose d’impopulaire : ils ont construit un harness d’évaluation exhaustif avant le déploiement large.

Ils ont créé un jeu de tests fixe de requêtes avec citations attendues. Tout changement de modèle ou de prompt devait passer : la réponse doit inclure des citations ; les citations doivent pointer vers des documents approuvés ; aucune PII dans la sortie ; latence sous un budget. Ils ont aussi implémenté la journalisation des requêtes avec redaction et stocké les IDs des documents récupérés en même temps que la réponse pour l’auditabilité.

Deux mois plus tard, le fournisseur de modèle en amont a changé de comportement. Pas de « downtime », juste un format de sortie différent et une propension légèrement différente à généraliser. Le harness l’a détecté le jour même parce que l’adhérence aux citations a chuté. L’équipe a gelé le déploiement, épinglé la version du modèle quand possible, et utilisé le mode de secours (« voici les documents ; pas de réponse synthétique ») jusqu’à re-validation.

Pas d’incident, pas d’escalade exécutive, pas de panique conformité. Les portes ennuyeuses ont fait ce que font les portes ennuyeuses : empêcher des pannes excitantes.

Playbook de diagnostic rapide : trouver le goulet en quelques minutes

Ceci est la version « astreinte à 2 h du matin ». Vous n’avez pas besoin d’une philosophie de l’IA. Vous avez besoin d’un coupable.

Première étape : est-ce le modèle, le réseau ou votre système ?

1. Vérifiez les symptômes visibles par l’utilisateur : est-ce lent, faux ou en échec ? Lent et en échec sont plus faciles que « faux ».
2. Vérifiez la santé des dépendances : limites de débit API LLM, timeouts, DNS, TLS, egress sortant, statut du fournisseur (si disponible).
3. Vérifiez la saturation de vos propres ressources : CPU, mémoire, utilisation GPU, profondeur des files, pools de threads, pools de connexions.

Deuxième étape : identifiez quelle étape domine

La plupart des fonctionnalités IA sont une pipeline :

• Parsing de la requête + auth
• Construction du prompt ou extraction de features
• Récupération (vector search / fetch base de données)
• Inférence (API distante ou modèle local)
• Post-traitement (validation, formatage, contrôles de politique)
• Écriture/caching

Chronométrez chaque étape. Si vous ne pouvez pas, ajoutez de l’instrumentation avant d’ajouter plus d’« IA ».

Troisième étape : arrêter l’hémorragie

• Activez le mode fallback (pas de génération, récupération seule, réponses mises en cache, ou désactivation du feature flag).
• Baissez la concurrence et appliquez des timeouts.
• Désactivez les retries sans budgets.
• Appliquez des limites au niveau edge ; protégez les services cœur avec des bulkheads.

Quatrième étape : décidez si vous avez un incident de correction

Si les utilisateurs rapportent « ça donne de mauvaises réponses », traitez cela comme une corruption de données : échantillonnez, reproduisez, trouvez un motif commun et arrêtez le déploiement. Les incidents de correction n’apparaissent pas dans les graphiques CPU.

Tâches pratiques avec commandes : des preuves plutôt que des impressions

Ces tâches sont orientées vers des serveurs Linux exécutant un service adjacent à l’IA (pipeline RAG, recherche vectorielle, passerelle modèle, ou serveur d’inférence local). Pour chacune : commande, ce que signifie la sortie, et la décision que vous prenez.

Tâche 1 : Confirmer la santé basique du service et le taux d’erreur (systemd + logs)

cr0x@server:~$ systemctl status ai-gateway --no-pager
● ai-gateway.service - AI Gateway
     Loaded: loaded (/etc/systemd/system/ai-gateway.service; enabled)
     Active: active (running) since Mon 2026-01-22 08:11:02 UTC; 3h 12min ago
   Main PID: 2147 (ai-gateway)
      Tasks: 38
     Memory: 612.3M
        CPU: 1h 44min

Signification : Le processus est en marche ; la mémoire et le CPU sont visibles. Cela ne prouve pas la correction ni la santé des upstreams.

Décision : Si pas active/en cours d’exécution, redémarrer et investiguer les crash loops. Si en cours, passer aux vérifications de latence et de dépendances.

cr0x@server:~$ journalctl -u ai-gateway -n 50 --no-pager
Jan 22 11:12:55 server ai-gateway[2147]: WARN upstream timeout model=vendor-llm request_id=9c2a...
Jan 22 11:12:55 server ai-gateway[2147]: WARN retrying attempt=2 backoff_ms=400
Jan 22 11:12:56 server ai-gateway[2147]: ERROR upstream rate_limited model=vendor-llm status=429

Signification : Vous n’êtes pas « down ». Vous êtes throttlé et en train de timeout. Les retries aggravent la situation.

Décision : Réduire la concurrence, appliquer des budgets de retry, envisager le mode fallback.

Tâche 2 : Mesurer p50/p95/p99 de latence au bord (logs nginx)

cr0x@server:~$ awk '{print $NF}' /var/log/nginx/access.log | tail -n 2000 | sort -n | awk 'NR==1000{p50=$1} NR==1900{p95=$1} NR==1980{p99=$1} END{print "p50="p50,"p95="p95,"p99="p99}'
p50=0.842 p95=6.913 p99=18.402

Signification : La médiane semble correcte ; la latence de queue est brutale. C’est généralement de la contention en amont, du rate limiting ou de la mise en file.

Décision : Cherchez les causes de la queue : timeouts, saturation, pools de connexions, requêtes de récupération lentes, ou profondeur de la file modèle.

Tâche 3 : Vérifier que DNS et TLS ne sont pas votre « problème IA »

cr0x@server:~$ dig +time=2 +tries=1 api.vendor-llm.internal A | sed -n '1,12p'
; <<>> DiG 9.18.24 <<>> +time=2 +tries=1 api.vendor-llm.internal A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4812
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; ANSWER SECTION:
api.vendor-llm.internal. 30 IN A 10.20.30.40

Signification : Le DNS se résout rapidement et correctement ici.

Décision : Si le DNS est lent ou en échec, corrigez resolvers/caching avant d’accuser le modèle. Si ok, testez connectivité et TLS.

cr0x@server:~$ openssl s_client -connect api.vendor-llm.internal:443 -servername api.vendor-llm.internal -brief < /dev/null
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: CN = api.vendor-llm.internal
Verification: OK

Signification : Le handshake TLS réussit ; le certificat vérifie. Si cela échoue de façon intermittente, votre « outage IA » pourrait venir d’une rotation PKI ou d’un problème MTU.

Décision : Si le handshake est lent/échec, investiguer le chemin réseau, proxies ou déploiement de certificat.

Tâche 4 : Vérifier les limites de débit et le mix d’erreurs amont (curl)

cr0x@server:~$ curl -s -D - -o /dev/null -m 10 https://api.vendor-llm.internal/v1/models
HTTP/2 200
date: Mon, 22 Jan 2026 11:18:02 GMT
x-ratelimit-limit-requests: 3000
x-ratelimit-remaining-requests: 12
x-ratelimit-reset-seconds: 23

Signification : Vous êtes près du bord. Les requêtes restantes sont faibles ; le reset est proche.

Décision : Ajoutez du throttling côté client et de la mise en file. Si vous ne pouvez pas, activez le cache ou dégradez gracieusement.

Tâche 5 : Vérifier si votre propre file est le goulet (backlog socket Linux + proxy métriques app)

cr0x@server:~$ ss -lntp | awk 'NR==1 || /:8080/'
State  Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 512    4096   0.0.0.0:8080      0.0.0.0:*     users:(("ai-gateway",pid=2147,fd=12))

Signification : Un Recv-Q élevé par rapport au trafic attendu suggère que l’app n’accepte pas assez vite ou est bloquée.

Décision : Si Recv-Q grimpe pendant les incidents, profilez les pools de threads, pauses GC, ou attentes en aval.

Tâche 6 : Identifier la saturation CPU et la pression de run queue

cr0x@server:~$ uptime
 11:19:44 up  3:22,  2 users,  load average: 18.42, 16.90, 15.77

Signification : Les load averages sont élevées. Sur un petit nombre de cœurs, vous êtes saturé CPU ou bloqué I/O avec de nombreuses tâches prêtes.

Décision : Vérifiez le nombre de cœurs, puis utilisez vmstat/top pour décider si c’est CPU ou attente I/O.

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
12  0      0  48212  21032 611204    0    0    10    24 1520 4820 78 12 10  0  0
15  0      0  47680  21032 611420    0    0    12    16 1602 5011 81 11  8  0  0

Signification : Un r élevé avec un wa faible implique une pression CPU, pas d’attente disque.

Décision : Scale out, réduire la concurrence, ou optimiser les chemins critiques (construction de prompt, parsing JSON, crypto, compression).

Tâche 7 : Trouver le processus coûteux et ses threads (top)

cr0x@server:~$ top -b -n 1 | sed -n '1,20p'
top - 11:20:31 up  3:23,  2 users,  load average: 19.02, 17.10, 15.92
Tasks: 238 total,  15 running, 223 sleeping,   0 stopped,   0 zombie
%Cpu(s): 84.5 us, 11.2 sy,  0.0 ni,  4.3 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :  15928.0 total,    121.4 free,   1912.5 used,  13894.1 buff/cache
PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
2147 app      20   0 3248216 612340  48212 R  720.1   3.8  105:12.33 ai-gateway

Signification : La gateway brûle du CPU sur de nombreux cœurs. C’est souvent de la sérialisation, tokenization, chiffrement, ou scoring de retrieval.

Décision : Profilez ; envisagez d’extraire le travail lourd hors du chemin de requête ; mettez en cache ; réduisez la verbosité des logs.

Tâche 8 : Vérifier la pression mémoire et le swap

cr0x@server:~$ free -m
               total        used        free      shared  buff/cache   available
Mem:           15928        1897         118          42       13912       13640
Swap:              0           0           0

Signification : Peu de « free » n’est pas un problème en soi ; « available » est sain. Aucun swap configuré.

Décision : La mémoire n’est probablement pas le goulet. Si « available » s’effondre ou qu’apparaissent des OOM, ajustez caches ou limites.

Tâche 9 : Si vous hébergez des modèles, vérifiez l’utilisation GPU et la marge mémoire

cr0x@server:~$ nvidia-smi
Wed Jan 22 11:22:06 2026
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 550.54.14              Driver Version: 550.54.14      CUDA Version: 12.4   |
|-----------------------------------------+----------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |         Memory-Usage | GPU-Util  Compute M. |
|                                         |                      |               MIG M. |
|=========================================+======================+======================|
|  0  NVIDIA A10G                    On   | 00000000:00:1E.0 Off |                    0 |
|  0%   61C    P0              142W / 150W|  22340MiB / 24564MiB |     98%      Default |
+-----------------------------------------+----------------------+----------------------+

Signification : Le GPU est saturé et la mémoire proche du plein. La latence de queue va grimper quand vous enfilez.

Décision : Réduire les tailles de batch, augmenter les réplicas, passer à un modèle plus petit, ou déléguer au provider externe pour les pics.

Tâche 10 : Confirmer la latence disque et la saturation (les index vectoriels font souvent mal)

cr0x@server:~$ iostat -xz 1 3
Linux 6.8.0-41-generic (server)  01/22/2026  _x86_64_  (16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          32.10    0.00    6.22    9.84    0.00   51.84

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   w_await aqu-sz  %util
nvme0n1        842.0  91320.0     12.0    1.4   14.82   108.4    112.0   1840.0    3.11   8.92   92.6

Signification : Forte charge de lecture et r_await élevé avec ~93% d’utilisation suggèrent que le stockage est un goulet (souvent scans d’index de retrieval ou compactions).

Décision : Optimisez la recherche vectorielle (paramètres HNSW, caching), augmentez la RAM pour l’index chaud, déplacez les index sur NVMe plus rapides, ou répartissez les shards.

Tâche 11 : Vérifier l’espace disque et l’épuisement des inodes (le tueur silencieux)

cr0x@server:~$ df -h /var/lib/vector
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p2  900G  874G   26G  98% /var/lib/vector

Signification : Vous êtes à 98% d’utilisation. Beaucoup de bases et constructeurs d’index se comportent très mal près des disques pleins.

Décision : Libérez de l’espace immédiatement ; arrêtez les compactions ; étendez le volume ; appliquez des politiques de rétention.

cr0x@server:~$ df -i /var/lib/vector
Filesystem        Inodes   IUsed     IFree IUse% Mounted on
/dev/nvme0n1p2  58982400 58611210   371190  99% /var/lib/vector

Signification : Les inodes sont épuisés. Vous pouvez avoir de l’espace mais toujours échouer à créer des fichiers.

Décision : Réduisez le churn de petits fichiers (nombre de segments, rotation de logs), reformatez avec plus d’inodes si nécessaire, ou consolidez la disposition du stockage.

Tâche 12 : Valider que votre cache fonctionne réellement (exemple Redis)

cr0x@server:~$ redis-cli INFO stats | egrep 'keyspace_hits|keyspace_misses|evicted_keys'
keyspace_hits:1829441
keyspace_misses:921332
evicted_keys:44120

Signification : Les misses sont nombreux et des évictions existent. Vous thrashez le cache, ce qui augmente probablement les appels upstream LLM et le coût.

Décision : Augmentez la taille du cache, corrigez les TTL, normalisez les clés cache, et cachez les résultats de récupération (pas seulement les réponses finales).

Tâche 13 : Détecter les tempêtes de retry via les logs de requêtes (grep + counts)

cr0x@server:~$ grep -c "retrying attempt" /var/log/ai-gateway/app.log
18422

Signification : Les retries sont fréquents ; pendant un incident ce nombre va sauter.

Décision : Appliquez un budget de retry par requête, ajoutez du jitter, et évitez les retries sur 429 sauf indication via Retry-After.

Tâche 14 : Vérifier si votre usage de tokens (proxy coût) explose

cr0x@server:~$ awk '/tokens_in=/{for(i=1;i<=NF;i++) if($i ~ /tokens_in=/){split($i,a,"="); in+=a[2]} if($i ~ /tokens_out=/){split($i,b,"="); out+=b[2]}} END{print "tokens_in="in, "tokens_out="out}' /var/log/ai-gateway/app.log
tokens_in=9284410 tokens_out=16422033

Signification : Les tokens de sortie dépassent de beaucoup les tokens d’entrée. Cela peut être normal pour de la summarisation ; c’est catastrophique pour des fonctionnalités de « réponse courte ».

Décision : Resserrez le max tokens, forcez des formats concis, et introduisez des séquences d’arrêt ou des sorties structurées.

Tâche 15 : Valider la latence des requêtes DB vectorielle (exemple PostgreSQL + pgvector)

cr0x@server:~$ psql -d rag -c "EXPLAIN (ANALYZE, BUFFERS) SELECT id FROM docs ORDER BY embedding <-> '[0.1,0.2,0.3]' LIMIT 5;"
                                                    QUERY PLAN
------------------------------------------------------------------------------------------------------------------
 Limit  (cost=0.42..1.05 rows=5 width=8) (actual time=42.118..42.140 rows=5 loops=1)
   Buffers: shared hit=120 read=980
   ->  Index Scan using docs_embedding_hnsw on docs  (cost=0.42..1200.00 rows=10000 width=8) (actual time=42.116..42.136 rows=5 loops=1)
 Planning Time: 0.312 ms
 Execution Time: 42.202 ms

Signification : 42 ms peut être acceptable, mais notez les lectures disque élevées. Sous charge, cela devient de la latence de queue.

Décision : Augmentez shared buffers, réchauffez l’index, améliorez la localité (moins de shards par nœud), ou ajustez les paramètres d’index pour échanger précision contre vitesse.

Tâche 16 : Confirmer que le kernel/chemin réseau ne perd pas de paquets (ss + retrans)

cr0x@server:~$ ss -ti dst api.vendor-llm.internal | sed -n '1,20p'
ESTAB 0 0 10.0.1.10:51244 10.20.30.40:https users:(("ai-gateway",pid=2147,fd=33))
	 cubic wscale:7,7 rto:204 rtt:32.1/4.0 ato:40 mss:1448 pmtu:1500 rcvmss:1448 advmss:1448 cwnd:10 bytes_acked:128394 segs_out:402 segs_in:377 send 3.6Mbps lastsnd:12 lastrcv:10 lastack:10 pacing_rate 7.2Mbps retrans:4/210

Signification : Des retransmissions existent. Si les retrans spikes pendant les incidents, votre « lenteur modèle » peut venir d’une perte de paquets.

Décision : Investiguer congestion réseau, mismatch MTU, tables d’état de pare-feu, ou épuisement NAT.

Erreurs courantes : symptômes → cause racine → correction

1) Symptom : « C’est up, mais les réponses sont pires »

Cause racine : Dérive de la distribution des entrées, changements du corpus de récupération, ou changement de comportement du modèle amont ; absence de monitoring de correctitude.

Correction : Construire un jeu d’évaluation fixe ; suivre la qualité des réponses avec labels humains ou métriques proxy ; ajouter détection de dérive sur les thèmes de requête et la distribution des docs récupérés ; ajouter un fallback sûr (retrieval-only).

2) Symptom : p50 ok, p99 catastrophique

Cause racine : Mise en queue sous charge, limites de débit, saturation GPU, ou I/O de récupération lente.

Correction : Limiter la concurrence ; ajouter du backpressure ; prioriser les requêtes ; pré-calculer embeddings ; déplacer la récupération en mémoire ; appliquer timeouts et abandonner le travail tardif.

3) Symptom : Les coûts grimpent sans que le trafic n’augmente

Cause racine : Tempêtes de retry, gonflement de prompts, misses cache, ou réponses trop verbeuses.

Correction : Budgets de retry ; limites de taille de prompt ; caps sur les tokens de sortie ; normaliser les clés cache ; cacher les résultats intermédiaires de retrieval.

4) Symptom : 429s et timeouts aléatoires, surtout aux pics

Cause racine : Rate limiting du fournisseur ou saturation de vos pools de connexion.

Correction : Rate limiting côté client (token bucket) ; respecter Retry-After ; implémenter de la mise en file ; stratégie multi-fournisseur avec comportements cohérents.

5) Symptom : « La sécurité dit non » et vous stagnez des mois

Cause racine : Pas de classification des données, rétention floue, et prompts contenant du contenu sensible.

Correction : Redaction avant envoi ; allowlists pour la récupération ; chiffrement ; politiques de rétention claires ; nettoyage des logs ; réaliser un threat model incluant prompt injection et exfiltration.

6) Symptom : Super demo, adoption nulle

Cause racine : La fonctionnalité ne s’intègre pas au flux de travail ; latence trop élevée ; résultats peu fiables ; pas de retour en arrière.

Correction : Mode consultatif ; citations en ligne ; UX rapide « accepter/éditer » ; afficher la confiance et les sources ; conserver le flux existant intact.

7) Symptom : Le système « bloque » sous charge puis récupère

Cause racine : Head-of-line blocking, retries synchronisés, ou pauses GC dues à de gros prompts/logging.

Correction : Séparer les files par priorité ; backoff avec jitter ; streaming de réponses si possible ; limiter la taille des payloads ; réduire le logging synchrone.

8) Symptom : Escalades juridiques/compliance après le rollout

Cause racine : Génération sans bornes sans contrôles de politique ; sorties qui engagent ou donnent des conseils régulés.

Correction : Filtres de sortie ; templates contraints ; disclaimers explicites si nécessaire ; router les intents à haut risque vers des humains ; logs d’audit avec citations.

Listes de contrôle / plan pas à pas

Étapes pas à pas : livrer une fonctionnalité « IA » sans transformer l’astreinte en art performance

1. Rédiger un énoncé de problème non-IA. Si vous ne le pouvez pas, arrêtez-vous. Vous êtes sur le point de construire du théâtre.
2. Choisir la classe de fonctionnalité : déterministe, probabiliste ou consultative. Par défaut, choisir consultative.
3. Définir des SLOs : disponibilité, latence (p95/p99), et un proxy de correctitude. Mettez-les par écrit.
4. Définir des budgets : coût max par requête, plafond mensuel, et un seuil « couper ».
5. Concevoir des fallbacks : réponse mise en cache, retrieval-only, règles, ou « fonctionnalité éteinte ». Assurez-vous que les flux principaux fonctionnent toujours.
6. Ajouter des garde-fous : validation d’entrée, taille max de prompt, max tokens, timeouts, disjoncteurs et limites de débit.
7. Instrumenter par étape : construction du prompt, retrieval, inférence, post-traitement, writeback. Vous avez besoin d’une répartition de latence.
8. Construire un harness d’évaluation : requêtes tests fixes, citations attendues, prompts red team, seuils de régression.
9. Faire un déploiement progressif : utilisateurs internes → petit cohort → cohortes plus larges. Surveillez le p99 et la correctitude.
10. Organiser un game day : simulez 429 amont, ralentissements, mauvaises sorties et dérive. Entraînez-vous à basculer les fallbacks.
11. Operationaliser la gestion des changements : versionnez les prompts, épinglez les modèles quand possible, tracez les versions de corpus et documentez les notes de release.
12. Établir la responsabilité : qui approuve les changements de prompt/modèle, qui possède le runbook d’astreinte, qui possède les alarmes budget.

Checklist : ce qu’il faut interdire par défaut en production

• Retries non bornés vers un fournisseur LLM upstream.
• Timeouts « best effort » (tout ce qui dépasse la fenêtre de patience de l’utilisateur).
• Livrer sans rollback ni mode fallback.
• Logger des prompts/réponses bruts contenant des données clients.
• Permettre au texte généré de déclencher des actions irréversibles (remboursements, suppressions, changements de compte) sans porte déterministe.
• « Un modèle pour les gouverner tous » sans évaluation sur les cas d’usage.

Checklist : signaux sur lesquels alerter

• Latence p99 par étape de pipeline (retrieval vs inférence vs post-process).
• Taux 429 et 5xx des fournisseurs upstream.
• Taux d’éviction et hit ratio du cache.
• Usage de tokens par requête (in/out), plus la variance.
• Profondeur de la queue et temps en file.
• Proxies de correctitude : taux de citation, échecs de validation, « pouces vers le bas » utilisateur, taux d’escalade.
• Indicateurs de dérive : distribution des sujets de requête, déplacements de distance d’embedding, changements de distribution des documents récupérés.

FAQ

1) L’« IA partout » est-elle toujours mauvaise ?

Non. C’est mauvais quand l’étiquette remplace les exigences. Mettez l’IA là où une aide probabiliste est acceptable : rédaction, résumé, recherche, suggestions de routage. Soyez conservateur sur les actions automatisées.

2) Quelle est la plus grande différence opérationnelle entre le logiciel classique et les fonctionnalités IA ?

La correctitude devient statistique et évolutive dans le temps. Votre système peut être sain et faux. Vous avez besoin de harness d’évaluation et de surveillance de dérive, pas seulement de checks d’uptime.

3) Devrions-nous héberger les modèles nous-mêmes ou utiliser un fournisseur ?

Choisissez le mode de défaillance que vous pouvez opérer. Les fournisseurs réduisent la charge infra mais ajoutent limites de débit, changements opaques et risque de dépendance. L’auto-hébergement donne du contrôle mais exige ordonnancement GPU, capacity planning et surface de sécurité. L’hybride est courant : auto-héberger pour des charges prévisibles, fournisseur pour les pics.

4) Que mesurer en premier si on n’a rien aujourd’hui ?

Répartition de latence par étape, mix d’erreurs amont (429/5xx/timeouts), usage de tokens par requête, hit ratio du cache, et un proxy unique de correctitude (feedback utilisateur ou taux de validation).

5) Comment empêcher que les « changements de prompt » deviennent des changements de production non relus ?

Versionnez les prompts comme du code. Exigez une revue. Exécutez un suite d’évaluation en CI. Loggez la version du prompt par requête. Traitez les éditions de prompt comme des releases.

6) Quel est le fallback le plus simple et sûr pour une fonctionnalité LLM ?

Retrieval-only : renvoyer les documents/snippets principaux avec liens/titres (interne) et laisser les utilisateurs lire. C’est moins magique et bien plus fiable.

7) Comment gérer les hallucinations sans faire semblant qu’elles n’existent pas ?

Contraignez les sorties (formats structurés), exigez des citations, validez les affirmations contre des champs connus, et routez les cas à fort impact vers des humains. Mesurez aussi le taux d’hallucination via des audits.

8) Cacher les réponses LLM aide-t-il réellement ?

Oui, si vous normalisez les entrées et acceptez que certaines sorties puissent être réutilisées. Cachez les résultats de retrieval, les embeddings et le post-traitement déterministe aussi. Ne cachez pas de réponses sensibles sans politique claire.

9) Quel est le piège de coût le plus courant ?

Retries plus sorties verbeuses. Vous payez la même requête plusieurs fois, puis encore pour des tokens excessifs. Budgétez les retries et limitez la génération.

10) Comment expliquer la fiabilité IA à des dirigeants qui veulent juste le badge ?

Traduisez en risques : latence de queue, dépendance fournisseur, régressions de correctitude et exposition compliance. Proposez ensuite un déploiement progressif avec métriques mesurables et interrupteurs d’arrêt.

Conclusion : prochaines étapes réalisables cette semaine

« IA partout » n’est pas une stratégie. C’est une étiquette. Votre travail est de transformer des étiquettes en systèmes qui se comportent sous pression.

1. Choisissez une fonctionnalité IA et écrivez sa métrique d’impact, sa métrique de dommage, son budget de latence et son budget de coût sur une page.
2. Ajoutez un mode fallback qui préserve le flux lorsque le modèle est lent, faux ou rate-limité.
3. Instrumentez la latence par étape pour pouvoir répondre à « où est passé le temps ? » sans deviner.
4. Construisez un petit harness d’évaluation (20–50 requêtes représentatives) et exécutez-le avant chaque changement de prompt/modèle/corpus.
5. Définissez des alertes sur les 429, retries, usage de tokens, évictions de cache et p99 par étape. Pas parce que les alertes sont amusantes — parce que les surprises coûtent cher.

Si vous faites ces cinq choses, l’étiquette peut rester ridicule pendant que la fonctionnalité devient réelle. C’est le seul compromis qui fonctionne en production.