Chaque équipe proposant des fonctionnalités d’IA a une histoire sur ce qu’elle a failli publier. Le chatbot qui a donné des conseils médicaux n’aurait pas dû. Le système de recommandation qui faisait apparaître un contenu que personne dans l'équipe n'aurait approuvé s'il l'avait vu. L'intégration du modèle de langage qui mémorisait et régurgitait les informations personnelles d'une personne.
Les équipes chanceuses les ont détectés avant les utilisateurs. Les malchanceux l’ont découvert grâce au Twitter.
La différence entre ces deux résultats ne réside généralement pas dans une meilleure infrastructure de test ou dans des ingénieurs plus intelligents. Il s'agit de savoir si l'équipe avait l'habitude de prendre du recul et de poser des questions difficiles sur ce que faisait réellement son système d'IA dans le monde réel. Cette pratique est une rétrospective sur l’éthique et la sécurité – et si vous proposez des fonctionnalités d’IA, vous en avez besoin.
Pourquoi les rétros standards manquent les problèmes d'éthique de l'IA
Votre rétrospective de sprint régulière est conçue pour mettre en évidence les problèmes de processus : révisions de code lentes, exigences peu claires, frictions de déploiement. Il n’est pas conçu pour faire apparaître les types de questions qu’exige l’éthique de l’IA, telles que :
- Notre modèle se comporte-t-il différemment selon les différents groupes démographiques ?
- Que se passe-t-il lorsque quelqu’un essaie délibérément de faire en sorte que notre IA produise des résultats nuisibles ?
- Sommes-nous en train de collecter ou de conserver des données que nous ne devrions pas collecter ?
- Qui sera lésé si notre IA se trompe, et à quel point ?
Ces questions n’émergent pas naturellement sous la forme « ce qui s’est bien passé/ce qui pourrait s’améliorer ». Ils nécessitent des incitations délibérées, des données spécifiques et un type de conversation différent de celui auquel la plupart des équipes sont habituées.
Cela ne signifie pas que vous avez besoin d’un processus lourd distinct. Cela signifie que vous devez avoir l'intention de créer régulièrement un espace pour ces questions, qu'il s'agisse d'une session mensuelle dédiée ou d'un segment récurrent dans vos rétros existantes.
Les quatre domaines qui comptent
Lorsque vous évaluez l'éthique et la sécurité d'un système d'IA, il est utile de disposer d'un cadre cohérent afin de ne pas manquer d'angles morts. Voici quatre domaines qui couvrent le terrain dont la plupart des équipes ont besoin :
1. Équité et partialité
La question ici est simple : votre IA traite-t-elle équitablement différents groupes de personnes ? La réponse n’est presque jamais simple.
Commencez par ce que vous pouvez mesurer. Si votre système prend des décisions concernant les personnes (recommandations, notation, filtrage, classement), répartissez les résultats par dimensions démographiques auxquelles vous pouvez accéder. Recherchez les disparités. Si votre modèle de modération de contenu signale les publications de certaines communautés à des tarifs plus élevés, cela vaut la peine d'être étudié.
Pour votre rétrospective, demandez :
- Avons-nous testé le comportement de notre modèle sur différents groupes démographiques au cours du mois dernier ?
- Des plaintes ou des commentaires d'utilisateurs suggèrent-ils un traitement biaisé ?
- Nos ensembles de données de formation sont-ils représentatifs de notre base d’utilisateurs réelle ?
- Quelles hypothèses sont intégrées à notre modèle et que nous n'avons pas examinées récemment ?
La réponse honnête à la plupart de ces questions pour la plupart des équipes est « nous n’avons pas vérifié ». Ce n'est pas grave, c'est par la rétrospective que vous décidez de commencer.
2. Sécurité et prévention des dommages
Cela couvre les façons dont votre système d'IA pourrait nuire directement aux utilisateurs : générer des instructions dangereuses, produire du contenu qui ne devrait pas exister, commettre des erreurs à enjeux élevés ou être manipulé pour adopter un comportement que vous n'aviez pas prévu.
La gravité dépend entièrement de votre contexte. Un chatbot qui écrit de la mauvaise poésie n’a que peu d’enjeu. Un système qui conseille les patients sur la posologie des médicaments est une question de vie ou de mort. Votre rétrospective doit refléter le niveau de risque réel de votre produit spécifique.
Questions rétro utiles :
- Avons-nous rencontré des cas où notre IA a produit des résultats susceptibles de nuire à un utilisateur ?
- Quelqu'un a-t-il testé des entrées contradictoires depuis notre dernier examen ? Ce qui s'est passé?
- Nos filtres de contenu et nos garde-fous de sécurité fonctionnent-ils comme prévu ? Qu'est-ce qui passe ?
- Si notre modèle est erroné dans le pire des cas, quelle est la conséquence ?
3. Transparence et explicabilité
Les utilisateurs interagissant avec l'IA méritent de savoir certaines choses : s'ils interagissent avec l'IA, dans quelle mesure le système est fiable et, si possible, pourquoi il a produit un résultat particulier.
C'est en partie une question UX et en partie une question éthique. Si votre robot de service client basé sur l'IA ne s'identifie pas comme tel, les utilisateurs peuvent partager des informations qu'ils ne partageraient pas avec une machine. Si votre système de recommandation n’explique pas pourquoi il suggère quelque chose, les utilisateurs ne peuvent pas évaluer la suggestion de manière significative.
Pour le rétro :
- Les utilisateurs savent-ils quand ils interagissent avec un système d’IA ?
- Communiquons-nous les niveaux de confiance ou d’incertitude d’une manière que les utilisateurs peuvent comprendre ?
- Pouvons-nous expliquer les résultats de notre modèle lorsque quelqu'un nous le demande ? Pouvons-nous le faire dans un langage non technique ?
- Avons-nous été transparents sur les limites de nos fonctionnalités d’IA ?
4. Confidentialité et traitement des données
Les systèmes d’IA sont gourmands en données, et la frontière entre « les données dont nous avons besoin pour que le modèle fonctionne » et « les données que nous ne devrions pas collecter » peut rapidement s’estomper. Les modèles de langage en particulier peuvent mémoriser les données de formation, ce qui crée de réels risques pour la vie privée si l'une de ces données était personnelle.
Questions rétro :
- Quelles données alimentons-nous dans notre modèle et avons-nous un consentement clair pour cette utilisation ?
- Avons-nous testé si notre modèle peut être invité à révéler des données d'entraînement ou des informations personnelles ?
- Conservons-nous les interactions des utilisateurs ? Pendant combien de temps et qui y a accès ?
- Sommes-nous conformes aux réglementations en matière de protection des données qui s'appliquent à nos utilisateurs ?
Organiser la rétrospective
Qui devrait être dans la pièce
Il ne s'agit pas simplement d'un exercice d'ingénierie. Vous avez besoin de personnes qui comprennent techniquement le système (ingénieurs, praticiens du ML) ET de personnes qui comprennent son impact humain (chefs de produit, concepteurs, toute personne occupant un rôle en contact avec le client). Si vous avez des collaborateurs juridiques ou chargés de la conformité, incluez-les périodiquement – pas à chaque session, mais tous les trimestres.
Gardez le groupe entre 4 et 8 personnes. Les groupes plus nombreux rendent plus difficile les conversations honnêtes, parfois inconfortables, requises par ce format.
Un format pratique (60 minutes)
Examinez les données (15 minutes). Avant la réunion, quelqu'un doit préparer un bref résumé des signaux pertinents : plaintes des utilisateurs, journaux de modération, tendances des mesures de sécurité, résultats des tests de biais, incidents pertinents ou quasi-accidents. Parcourez cela rapidement pour ancrer la conversation sur ce qui se passe réellement.
Discutez de chaque domaine (30 minutes). Vous n'avez pas besoin de couvrir les quatre domaines à chaque session. Faites pivoter la mise au point et passez plus de temps sur les zones où vous avez vu des signaux ou dans lesquelles vous n'avez pas vérifié depuis un certain temps. La discussion doit être centrée sur : qu’avons-nous appris, de quoi sommes-nous inquiets et sur quoi devrions-nous approfondir nos recherches.
Décidez des actions (15 minutes). Choisissez 1 à 3 suivis concrets. Exemples :
- Exécutez un audit de biais sur le modèle de recommandation avant la rétro du mois prochain
- Ajouter des tests contradictoires au processus d'assurance qualité pour le chatbot
- Mettre à jour l'avis de confidentialité pour refléter la façon dont nous utilisons les données conversationnelles
- Mettre en place une surveillance automatisée pour un mode de défaillance spécifique que nous avons identifié
Le rendre durable
Le plus gros risque n'est pas d'exécuter un mauvais rétro - il s'arrête après trois séances parce que cela semble être une surcharge. Voici comment éviter cela :
Commencez mensuellement, pas hebdomadairement. Les examens éthiques nécessitent suffisamment de temps entre les sessions pour que les nouvelles données s'accumulent et que les actions soient effectuées.
Faites pivoter l'animateur. Cela évite qu'il s'agisse d'une « initiative d'une seule personne » et répartit le sentiment d'appropriation au sein de l'équipe.
Connectez-le à des incidents réels. Lorsque quelque chose ne va pas – une plainte d'un utilisateur concernant un biais, un résultat qui n'aurait pas dû se produire, un quasi-accident – faites-y référence dans la prochaine rétro. Cela renforce le fait que les séances ont un objectif au-delà du théâtre de conformité.
Tenez un journal en cours. Documentez ce dont vous avez discuté, ce que vous avez décidé et ce qui s'est passé en conséquence. Au fil du temps, ce journal devient une connaissance institutionnelle précieuse et une preuve que votre équipe prend l'éthique au sérieux, si jamais cela compte (et cela pourrait un jour).
Modèles courants et que faire à leur sujet
Après les avoir exécutés pendant un certain temps, vous remarquerez des thèmes récurrents. Voici ceux qui reviennent le plus souvent :
"Nous n'avons pas les données nécessaires pour évaluer l'équité." Ceci est courant et réel. Si vous n’avez pas mis en place de tests démographiques, vous ne pouvez pas mesurer les biais démographiques. L'objectif n'est pas d'avoir une discussion philosophique, mais de définir les données dont vous auriez besoin et de déterminer comment les obtenir de manière éthique.
"Nous savons qu'il y a un problème mais le résoudre coûte cher." C'est là que la priorisation devient inconfortable. Un problème de biais dans votre modèle peut nécessiter un recyclage, ce qui peut prendre des semaines. Le rétro-éclairage doit produire une évaluation honnête des risques : quelle est la gravité du préjudice, quelle est sa probabilité et quel est le coût de sa réparation ou de son absence de réparation ? Transmettez ensuite ce compromis à celui qui détient la décision.
"Les tests de sécurité ne cessent de perdre la priorité des fonctionnalités." Si cela apparaît à plusieurs reprises, il s'agit d'un problème systémique. Le correctif ne se situe pas au niveau de l'équipe, mais au niveau de la feuille de route. Utilisez les données rétrospectives pour faire valoir auprès des dirigeants que le travail de sécurité nécessite des capacités protégées.
"Nous ne sommes pas sûrs de ce que la réglementation exige." Ceci est de plus en plus courant à mesure que la réglementation sur l'IA évolue d'une juridiction à l'autre. L'action à entreprendre est spécifique : obtenez un briefing du service juridique, lisez la réglementation pertinente (la loi européenne sur l'IA est la plus complète au début de 2026) et identifiez ce qui s'applique à la classification des risques de votre système.
Vers une culture de sécurité
Le but des rétrospectives sur l’éthique et la sécurité n’est pas de cocher une case ou de protéger l’entreprise de toute responsabilité (bien qu’elle le fasse aussi). Il s'agit de créer une habitude d'équipe consistant à demander « devrions-nous ? » à côté de "pouvons-nous?"
Au fil du temps, ces conversations changent la façon dont les gens pensent pendant le développement, et pas seulement pendant les révisions. Les ingénieurs commencent à signaler les problèmes potentiels d’équité lors des discussions de conception. Les chefs de produit commencent à poser des questions sur les modes de défaillance dans les PRD. La rétrospective ne fait pas que révéler les problèmes : elle apprend à l'équipe à les voir plus tôt.
C'est le véritable résultat que vous recherchez : une équipe où la réflexion sur l'éthique et la sécurité est intégrée au travail, et non ajoutée après coup.
Essayez NextRetro gratuitement — Utilisez le mode anonyme pour faire ressortir les préoccupations éthiques sensibles que votre équipe pourrait ne pas soulever ouvertement.
Dernière mise à jour : février 2026
Temps de lecture : 7 minutes
