Préferences

Votre vie privée est essentielle pour nous. Vous pouvez donc désactiver certaines catégories de cookies ou autres traceurs qui ne sont pas indispensables au bon fonctionnement du site. Sachez toutefois que bloquer ces catégories peut réduire la qualité de votre expérience de navigation. En savoir plus

Accepter tous les cookies

Ces éléments sont indispensables au fonctionnement de base du site Web.

Toujours Actif

Ces éléments sont utilisés pour diffuser des annonces plus pertinentes pour vous et vos centres d’intérêt.

Ces éléments permettent au site Web de se souvenir des choix que vous effectuez (par exemple votre nom d’utilisateur, votre langue ou votre région) et d’offrir des fonctionnalités améliorées et plus personnalisées.

Ces éléments aident notre équipe à comprendre les performances du site, la manière dont les visiteurs interagissent avec celui-ci, et à détecter d’éventuels problèmes techniques.

Tout refuserConfirmer
Vos préférences sont bien enregistrées !
Oups ! Une erreur est survenue lors de l’envoi de vos préférences.

L’architecture du choix à l’ère de l’IA

metadata
DATE :
22.09.2025
AUTEUR :
Alexandre BERNELIN
Temps de lecture :
5 minutes
Article

Éditorialiser les données d’entraînement pour mettre l’IA “à sa main”

Note — Ce texte est issu d’une conférence tenue lors de la France Design Week, dans le cadre d’un événement de l’Agence de l’Innovation de Défense (DGA). Il développe une thèse simple : à l’ère des génératives, éditorialiser les données d’entraînement permet de transformer le brief en spécifications computationnelles, de mettre l’IA à sa main et, in fine, de spécifier autrement.

Générer n’est pas décider. Les génératives compressent le temps de matérialisation (rendus, 3D, variantes). Le gain est réel : moins de temps pour produire, plus de temps pour choisir. Mais choisir quoi, sur quelle base, et pourquoi ?

Données généralistes ⇒ résultats imprécis

Par défaut, une IA entraînée sur des corpus généralistes renvoie une SORTIE STATISTIQUEMENT PROBABLE : correcte en moyenne, imprécise dans le détail.


Normal : l’IA encode des corrélations apprises dans ses données d’entraînement ; hors domaine, elle recombine l’habituel plutôt qu’elle n’atteint la justesse contextuelle.

Conclusion : si l’on veut de la justesse, il faut donner de la matière utile à la machine, pas seulement des prompts.

Ajouter de la donnée… oui, mais éditorialisée

“Plus de données” ne suffit pas. Il faut éditorialiser les données d’entraînement (ou d’adaptation) :

  • Provenance & droits : sources, licences, consentements, souveraineté.
  • Qualité & couverture : contextes, edge cases, fraîcheur ; signal/bruit.
  • Annotation & biais : schéma de labels, équité par sous-populations.
  • Traçabilité : lineage, versions, journalisation, contrôles de dérive.

Trois voies complémentaires pour exploiter cette matière :

  1. Fine-tuning / Domain adaptation : spécialiser le modèle avec des exemples représentatifs du projet.
  2. RAG (Retrieval-Augmented Generation) : brancher la génération sur un index documentaire dédié au périmètre.
  3. Évaluations dédiées (EVAL) : mesurer l’effet réel (labo et terrain) pour éviter l’illusion de progrès.

Faire de l’IA un outil à sa main

Éditorialiser la donnée transforme un brief techno/marketing en brief design computationnel — lisible par la machine et utile au métier :

  • Critères calculables (unités, seuils, méthodes de mesure)
  • Jeux de test indépendants de l’entraînement
  • Données d’entrée prêtes pour l’IA et compréhensibles par les équipes

On ne demande plus « fais joli », mais « respecte ces critères, atteins ces seuils, prouve-les ainsi ».


Le design redevient architecture du choix : du rendu à un verdict explicable.

En pratique : comparer, puis valider (sur preuves)

Comparer (évaluer des options)

  • Métriques d’usage : temps-à-tâche, erreurs, compréhension au 1er coup d’œil, accessibilité, coût.
  • Pondérations transparentes : scorecard multi-critères (poids assumés).
  • Labo + terrain : mêmes métriques en environnement contrôlé et en contexte réel.
  • Évidence jointe : captures, logs, A/B, jeux EVAL séparés de l’entraînement.

Valider (go / no-go)

  • Tests d’acceptation : pass/fail (normes, risques).
  • Robustesse & non-régression : variabilité de contexte, stabilité dans le temps.
  • Niveau de confiance : tailles d’échantillon, IC/p-value, MDE.
  • Traçabilité : specs-as-code, decision log (qui, quoi, quand, pourquoi).

Défense : le besoin d’en connaître, la donnée terrain et la “régurgitation”

Dans la défense, le besoin d’en connaître impose une règle simple : une IA ne doit voir que les données nécessaires au périmètre du projet.

  • La donnée terrain est cruciale (réalité d’usage), mais classifiée : collecte cadrée, anonymisation, journalisation, cloisonnement.
  • Les accréditations ne suffisent pas à éviter la régurgitation d’un projet vers un autre si l’on mélange les corpus.
  • Recommandation : adopter des modèles (ou adaptateurs) et/ou index RAG par projet, avec politiques de non-contamination (espaces de noms séparés, interdiction de ré-entraînement croisé, rétention zéro hors périmètre).

Objectif : garantir le besoin d’en connaître, réduire les fuites potentielles et empêcher l’“effet perroquet” de projet en projet.

À retenir

  • Une IA généraliste produit une SORTIE STATISTIQUEMENT PROBABLE ; pour la justesse, éditorialisez les données d’entraînement.
  • L’IA encode des corrélations : fournissez-lui des corrélations pertinentes (métier, terrain, cas limites) et des tests qui comptent.
  • Éditorialiser = transformer le brief en spécifications computationnelles ; c’est ainsi qu’on met l’IA “à sa main”.
  • En défense, le besoin d’en connaître et le risque de régurgitation imposent un cloisonnement fort : un modèle/adaptateur et/ou un index RAG par projet, pas de mélange.

Avant d’être architecte des solutions, le designer devient architecte des données. Les données sont les fondations ; le design en fait des décisions.

Lightbox Image