IA “responsable” sur un site : le playbook minimal avant de ship

Intégrer un LLM sur un site, c’est facile. L’intégrer sans créer une fuite de données, une UX bancale, et une facture qui explose, c’est un autre sport.

Je te pose ici un playbook minimal. Pas une usine à gaz “compliance”, juste le socle pragmatique que j’attends avant de mettre le bouton en prod. Si tu coches ça, tu as déjà évité 80% des erreurs classiques.

1) Commence par cadrer le “job” de l’IA (et ce que tu refuses)

Avant de parler modèle, parle produit. Une IA web, c’est une feature, pas une démonstration.

• Cas d’usage précis : répondre à une question support, résumer une page, classer un ticket, générer un email, etc.
• Entrées autorisées : texte uniquement ? fichiers ? URL ? données du compte ?
• Sorties attendues : texte libre, JSON strict, action (outil), ou les trois ?
• Ce que tu refuses : médical, juridique, finance, conseils personnalisés, contenu adulte, etc. Écris-le.

Tu ne veux pas découvrir “ce que l’IA sait faire” en production. Tu veux définir ce qu’elle a le droit de faire.

2) Cartographie ton flux de données (sinon tu navigues à l’aveugle)

Fais un schéma simple, même moche :

• Quels champs viennent du user ? (texte libre, formulaire, upload)
• Quelles données viennent de ton backend ? (profil, commandes, tickets, contenu privé)
• Qu’est-ce qui part chez le fournisseur LLM ?
• Qu’est-ce qui est stocké chez toi ? (prompts, réponses, embeddings, traces)

À partir de là, tu peux prendre des décisions nettes : minimiser, masquer, couper, consigner. Sans ça, tu fais semblant.

3) PII : règle simple, tolérance faible

La plupart des drames viennent de là. Les utilisateurs collent n’importe quoi dans un champ texte, et ton app envoie ça à un tiers.

Le minimum acceptable

• Principe d’allowlist : quelles données perso peuvent sortir ? Le reste est bloqué ou masqué.
• Redaction côté serveur avant l’appel LLM. Pas “on fera attention dans le prompt”.
• Secrets : clés API, tokens, cookies, entêtes, tout ça ne doit jamais atteindre un modèle. Jamais.
• Pièces jointes : traite-les comme de la dynamite. Extraction, scanning, et politique stricte.

Redaction : fais-le de façon reproductible

Exemple très simple (et volontairement incomplet) pour nettoyer un input avant envoi. L’idée n’est pas de “tout détecter”, mais de mettre un garde-fou concret et testable.

type RedactionResult = { sanitized: string; removed: string[] };

export function redactPII(input: string): RedactionResult {
  const removed: string[] = [];
  let s = input;

  // Emails
  s = s.replace(/[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,}/gi, (m) => {
    removed.push(m);
    return "[EMAIL]";
  });

  // Numéros de téléphone (heuristique)
  s = s.replace(/\b(?:\+33|0)\s?[1-9](?:[\s.-]?\d{2}){4}\b/g, (m) => {
    removed.push(m);
    return "[PHONE]";
  });

  // Identifiants qui ressemblent à des tokens
  s = s.replace(/\b(sk-[a-zA-Z0-9]{20,}|ghp_[a-zA-Z0-9]{30,})\b/g, (m) => {
    removed.push(m);
    return "[SECRET]";
  });

  return { sanitized: s, removed };
}

Ensuite tu logges des métriques (combien de redactions, quels types), pas les valeurs supprimées.

4) Consentement et transparence : une UX propre, pas un bandeau ridicule

Si tu utilises des données utilisateur, ou que tu envoies des contenus à un prestataire, tu dois l’assumer dans l’interface.

• Micro-copy clair au bon endroit : “Votre message peut être traité par un service d’IA” + lien vers détails.
• Opt-out simple quand c’est pertinent (surtout pour des champs libres et sensibles).
• Mode “sans IA” si la feature est non essentielle. Le user ne doit pas être coincé.

Et si tu as un public B2B : prévois le réglage “désactiver l’IA pour l’organisation”. Ça évite des discussions pénibles après signature.

5) Rétention : ce que tu stockes, combien de temps, et pourquoi

Le réflexe “on log tout pour debug” est dangereux avec un LLM. Il faut une politique.

• Prompts / réponses : stocke seulement si tu as une vraie raison (qualité, support, litiges) et avec une durée définie.
• Logs applicatifs : privilégie des logs structurés avec identifiants, latence, tokens, codes d’erreur, pas le texte brut.
• Fournisseur LLM : vérifie les options de rétention et d’utilisation pour entraînement. Décide, documente, applique.
• Suppression : si un user supprime ses données, l’IA ne doit pas garder une copie planquée dans un “dataset d’evals”.

Tu n’as pas besoin d’être parano. Tu as besoin d’être cohérent.

6) Évaluations (evals) : sans mesure, tu pilotes à l’instinct

Le plus gros mensonge de l’IA web, c’est “ça marche”. Oui, aujourd’hui. Après un changement de prompt, de modèle, de contexte, tu n’en sais rien.

Le kit minimal d’evals

• Jeu de cas “golden” : 30 à 200 exemples représentatifs, versionnés. Pas des exemples flatteurs.
• Critères : utilité, exactitude, conformité (pas de PII, pas d’info interdite), format (JSON ok), ton.
• Tests de régression : à chaque changement de prompt, de modèle, de RAG, de règles.
• Human spot-check : un petit échantillonnage régulier. Les scores automatiques ne suffisent pas.

Si tu n’as le temps que pour une chose : fais un dataset minimal et rejoue-le à chaque déploiement. Tu verras des surprises.

7) Observabilité : tu veux des traces, pas un roman

En prod, tu dois répondre vite à trois questions : “qu’est-ce qui s’est passé”, “combien ça coûte”, “est-ce que ça se dégrade”.

Les métriques que je veux voir

• Latence (p50/p95), timeouts, retries, taux d’erreur par modèle et par route.
• Tokens (input/output), coût estimé, coût par feature, coût par org.
• Taux de refus / safe-completions : utile pour détecter un prompt mal cadré.
• Qualité proxy : thumbs up/down, reformulations, “réessayer”, abandon, escalade support.
• Incidents : pics d’usage, dérives de coût, réponses vides, boucles d’outil.

Logs : structure et corrélation

Chaque appel LLM doit avoir un request_id, un user_id/org_id, un model, un feature flag, et des compteurs. Le texte brut ? seulement sur un mode debug très encadré, échantillonné, et nettoyé.

8) Coûts et budgets : mets des limites, maintenant

Le coût LLM n’est pas un bug, c’est une propriété. Donc tu gères ça comme n’importe quelle ressource.

• Budget par org : soft limit (alert) + hard limit (dégradation contrôlée).
• Caps : limite de tokens par requête, taille max du contexte, taille max des uploads.
• Cache : sur les réponses “quasi-déterministes” (FAQ, résumé d’une page stable).
• Routing : petit modèle par défaut, gros modèle seulement quand le score de difficulté l’exige.

Ne lance pas une feature “illimitée” puis découvre ton pricing après. Tu vas souffrir.

9) Garde-fous sécurité : prompt injection et outils, le duo qui pique

Dès que ton IA a accès à des outils (rechercher dans des docs privées, appeler une API, envoyer un email), tu as une surface d’attaque.

• Tooling allowlist : l’agent ne peut appeler que des actions explicites, avec des schémas stricts.
• Contrôle serveur : l’IA ne décide pas des permissions. Elle propose, ton backend valide.
• Isolation des sources : une page web ou un document importé ne doit pas pouvoir “injecter” des instructions prioritaires.
• Encodage de sortie : si tu affiches du HTML, sanitize. Les sorties LLM sont du contenu non fiable.

Le bon réflexe : considérer le LLM comme un utilisateur externe. Pas comme une fonction interne.

10) Fallback UX : prévoir la panne et l’incertitude

Une IA ne sera pas fiable à 100%. Et elle aura des jours sans. Donc l’UX doit survivre.

• États : chargement, timeout, réponse partielle, indisponible.
• Alternative : recherche classique, articles suggérés, formulaire support, template prérempli.
• “Je ne sais pas” : c’est une réponse acceptable si elle renvoie vers une action utile.
• Escalade : quand la confiance est faible, propose “transférer au support” avec le contexte (nettoyé).

Un bon produit IA, ce n’est pas celui qui parle bien. C’est celui qui reste utilisable quand ça déraille.

11) Release : feature flags, ramp-up, et A/B si tu peux

Tu ne “déploies” pas une IA comme un formulaire. Tu la mets sous contrôle.

• Feature flag par environnement et par segment (admin, beta users, 10%, 50%, 100%).
• Ramp-up progressif pour surveiller qualité et coût.
• A/B sur un critère clair (résolution de tickets, conversion, temps gagné), pas sur “ça a l’air mieux”.
• Kill switch : un bouton pour couper l’IA sans redéployer toute l’app.

Checklist rapide (si tu veux l’imprimer dans ta tête)

• Flux de données cartographié
• PII minimisée + redaction serveur
• Consentement / transparence dans l’UI
• Rétention décidée et appliquée (chez toi + chez le vendor)
• Dataset d’evals versionné + régression à chaque change
• Observabilité: latence, erreurs, tokens, coût, feedback
• Budgets, caps, rate limits, cache
• Tooling sécurisé (allowlist, validations serveur)
• Fallback UX + kill switch
• Release progressive + monitoring serré

Mon avis (sec) : le “responsable”, c’est surtout du contrôle

On vend souvent “l’IA responsable” comme une posture. En pratique, c’est beaucoup plus simple et beaucoup plus concret.

Tu contrôles ce qui sort (PII), tu contrôles ce que tu stockes (rétention), tu contrôles la qualité (evals), et tu contrôles l’exploitation (observabilité, coûts, fallback). Le reste, c’est du storytelling.

Sources

• web.dev – Start our latest course, Learn AI!