Opérations et gouvernance → Éthique de la gestion opérationnelle

Éthique de la gestion opérationnelle

1) Pourquoi est-ce nécessaire

Les opérations sont des compromis constants « vitesse ↔ risque ↔ coût ». Le cadre éthique aide à prendre des décisions sous la pression des données, de l'argent et des délais pour ne pas tromper les utilisateurs et les steakholders, ne pas perturber la vie privée et ne pas compromettre la viabilité à long terme de la plate-forme.

• Définir des « lignes rouges » claires et des règles de comportement pour les commandes et il-colla.
• Assurer l'honnêteté des SLA, des métriques et des communications dans les incidents.
• Protéger la vie privée, les données et les droits des utilisateurs/partenaires.
• Rendre l'automatisation et l'IA gérables, compréhensibles et sécurisés.

2) Principes de base (noyau)

1. Safety first : les solutions ne doivent pas augmenter la probabilité de dommages aux utilisateurs/données.
2. Honnêteté des mesures : pas de métriques « cosmétiques », SSOT unique et reproductibilité.
3. Transparence des actions : qui a fait quoi, pourquoi, sur la base de quelles données.
4. Responsabilité et responsabilisation : rôle → pouvoirs → vérification → conséquences.
5. Minimisation des données : nous collectons uniquement le nécessaire, limitons l'accès et la durée de conservation.
6. Explosible Ops/AI : les solutions automatiques sont claires, réversibles et contestables.
7. L'équité et l'absence de discrimination : une politique « no bias » dans les règles et les modèles.
8. Blameless, mais pas sans objet : les erreurs sont une excuse pour changer le système, pas pour cacher des faits.

3) Éthique des métriques, SLO/SLA et rapports

• Définitions uniques des métriques (fenêtres, agrégateurs), versionage des formules.
• Il est interdit : de cacher les incidents dans les « travaux planifiés », de déplacer les fenêtres/zones temporelles pour les « beaux » SLA, d'exclure les données sans base documentaire.
• Étiquetage clair : « estimation », « prévision », « fait », « exclusion et motif ».
• Les postmortems sont publiés avec des faits et des actions, pas « PR ».

Anti-patterns : "deux versions p99", ajustement manuel des rapports, périodes sélectives "sans pics'.

4) La vie privée et le travail avec les données PII/de paiement

Minimisation : par défaut, PII ne quitte pas le circuit de production ; masques dans les loges/dashboards.
Accès par rôle : le principe du moindre privilège ; audit de chaque lecture de données sensibles.
Retraite : délais de conservation clairs, politique de suppression/anonymisation.
Incidents de données : notification immédiate des propriétaires/personnes morales par règlement.

Il est interdit : de transférer de vrais PII dans un steads/analysis sans anonymisation ; partager avec les vendeurs en dehors du contrat.

5) Communications éthiques dans les incidents

Vérité et actualité : ETA des statuts, langage clair, pas de silence.
Ne blâmez pas les individus : l'accent est mis sur les faits et les causes systémiques.
Pas de corrections « silencieuses » : les modifications affectant l'utilisateur doivent être désignées.
Limitation de la spéculation : « Nous vérifions X, prochain résumé à 20h15 ».

What is happening/who is affected/what we are doing/when the next update/where to follow

6) Éthique de l'automatisation et de l'IA dans les opérations

Périmètre clair : liste des actions que l'IA/bot peut faire sans confirmation (seulement réversible et à faible risque).
Explainability : à chaque recommandation sont les sources et les arguments, l'interdiction de « sans référence ».
HITL (personne en boucle) : confirmation des actions sensibles (transfert de trafic, changement de PSP, changement de limite).
Audit : Journal des prompts/actions/décisions, rapports de dry-run.
Bias & fairness : vérification régulière des recommandations de distorsion (géo, appareils, type de joueur).
Données pour l'IA : interdiction de « coller » PII/secrets ; utilisation de vitrines impersonnelles.

7) Relations avec les fournisseurs et conflits d'intérêts

SLA/OLA en langage SLO : carte honnête des dépendances ; faits publics sur les outsiders du vendeur.
Intérêts concurrents : ne pas prendre de décisions architecturales en raison de « bonus personnels/schémas de référence ».
Éthique des appels d'offres et des pilotes : tests comparables, critères de victoire documentés.
Interdit : cacher les défaillances du fournisseur comme « les nôtres », changer les métriques de comparaison « sous le vainqueur ».

8) « Lignes rouges » (non traduites)

Manipulation des données et des rapports.
Dissimuler les incidents qui affectent les utilisateurs/l'argent.
Utilisation de PII réels dans des environnements non protégés.
Automatiser les actions irréversibles sans HITL et plan de rollback.
Pression sur les employés pour « embellir » les métriques ou manquer le gate.

La violation est le déclencheur d'une enquête formelle, jusqu'à l'arrêt des sorties.

9) Politiques et normes (fragments)

- All metrics are described in the catalog with formula, window and owner.
- Formula change - via RFC and parallel run (old vs new).
- Any exceptions in the SLA are documented and signed by the parties.

- First summary of 15 minutes, then ETA.
- Tone: facts, hypotheses are marked, references to artifacts.
- It is forbidden to promise deadlines without justification (progress/plan/resources).

- Allowed: summaries, tickets, requests for observability, annotations, pre-scale (reversibly).
- Requires confirmation: feilover, changing limits, enabling safe-mode, canary pause.
- Required: activity log, explainability, dry-run before use.

10) Rôles et responsabilités

Head of Ops : propriétaire de politiques éthiques, autorité de la « grue stop ».
Responsable de l'incident : qualité et honnêteté des communications, contrôle post mortem.
SRE/Observability : métrique SSOT, audit des formules et alertes, protection contre les « cosmétiques ».
DPO/Sécurité : vie privée, accès, enquêtes sur les fuites.
Juridique/PR : conformité aux lois/contrats, communications externes.
Commandes de domaine : respect des gates, données correctes et artefacts.

11) Dashboards et artefacts d'éthique

Integrity Metrics : divergences de Online↔DWH, modifications de formules, panneaux obsolètes.
Incident Comms : temps avant la première mise à jour, respect de l'ETA, exhaustivité des résumés.
Privacy & Access : recours aux IPI, demandes anormales, délais de rétractation.
AI Governance : nombre d'autopsies, part de dry-run, pots-de-vin, décisions controversées.
Vendor Truth : incidents sur les fournisseurs, mise en correspondance de leurs rapports et de nos SLO.

12) Chèques-feuilles

• Il y a des ficheflags et un plan de retour.
• Les alertes SLO et les annotations sont incluses.
• Il n'y a pas de pression « d'en haut » pour contourner les gates.
• Les risques/exceptions sont documentés, harmonisés.

• Premier Apdate et ETA en temps opportun.
• Les faits sont séparés des hypothèses, des références aux données.
• Il n'y a aucune tentative de sous-estimer l'échelle/l'impact.
• Postmortem à la date limite, valable.

• La liste des autopsies autorisées a été approuvée.
• Le journal et l'explainability sont inclus.
• Le PII n'est pas utilisé/masqué.
• HITL pour les opérations sensibles.

13) KPI maturité éthique

Metrics Integrity Score (dérive Online↔DWH ≤ 2 %, proportion de formules versionnées ≥ 95 %).
Incident Comms SLA (premier résumé ≤ 15 min, respect de l'ETA ≥ 90 %).
Violations de la vie privée = 0, proportion d'accès aux IPI avec justification = 100 %.
Sécurité de l'IA : proportion d'autopsies réversibles = 100 %, retraits <5 %, cas controversés démantelés = 100 %.
Whistle Safety Index : les canaux anonymes fonctionnent, les appels sont traités ≤ 7 jours.

14) Anti-modèles

« Peindre l'herbe » : cosmétiques en métriques, redéfinir l'ALS « rétroactivement ».
« Les sorties de nuit sans drapeaux » pour les deadlines.
Chat privé et solutions sans journal.
Rétro/post-mortem toxique, la recherche des coupables.
IA sans RAG/explication, « boîte noire » dans les opérations.
Collecte de données « au cas où ».

15) Formulation pratique (peut être copié dans la politique)

We tell the truth about the state of the systems.
We do not hide incidents and do not distort metrics.
We protect user data and restrict access.
We automate only reversible and safe actions, the rest is through HITL.
We document decisions and respect the "stop crane."

- SLO/guard rails are active; rollback plan checked.
- Changes of metrics/formulas are formalized by RFC and announced.
- No conflicts of interest, decisions made on data.

16) 30/60/90 - plan de mise en œuvre

• Approuver les lignes rouges, le code, la politique de communication et de confidentialité.
• Désigner les propriétaires (Head of Ops, DPO, Observability).
• Démarrer Metrics Integrity et Incident Comms.

• Mettre en œuvre un RFC pour les formules métriques et SSOT ; recomposer les panneaux contestés.
• Formaliser le périmètre IA/bots (actions autorisées, HITL, journal).
• Dispenser une formation en éthique aux chefs de domaine et aux chefs de domaine.

• Effectuer une vérification de conformité, examiner les cas/plaintes, mettre à jour les politiques.
• Lier l'éthique KPI à l'OKR des commandes (par exemple, Incident Comms SLA, Integrity Score).
• Effectuer un rétro sur l'efficacité et l'ajustement des lignes rouges.

17) FAQ

Q : Qu'en est-il si une entreprise demande que le rapport de SLA soit « corrigé » ?
R : Refuser en invoquant la politique des métriques honnêtes et la SSOT. Proposer une alternative : la métrique « expérience utilisateur » avec des exceptions compréhensibles formalisées par le biais d'un contrat.

Q : Comment combiner vitesse de sortie et éthique ?
A : Petits incréments, ficheflags, canaris et auto-gates par SLO. L'éthique n'est pas un frein, mais une assurance contre les erreurs coûteuses.

Q : Quand reconnaître publiquement une erreur ?
R : Toujours lorsque l'impact est tangible pour les utilisateurs/partenaires. Modèle de statut + plan d'action + échéancier.