Depuis des mois, chez EKITE, nous avons en tête deux éléments bien intégrés à notre stratégie d’entreprise : la souveraineté numérique et le Numérique Responsable.

De mon côté, par rapport à ma capacité d’accompagnement, il y a eu beaucoup de réflexion autour de la deuxième thématique. J’avais noté quelques notes dans un coin de mon carnet numérique disponible sur le nuage. L’idée était de reprendre des artéfacts existants et de les saupoudrer de nouveaux angles fondés sur ma récente prise de conscience sur notre responsabilité en tant qu’acteurs du numérique.

Alors j’ai travaillé sur plusieurs items classiques dans le Product Management. Vous le savez, j’aime le partage, alors voici deux reboots d’artéfact qui pourraient vous aider à adopter les bons réflexes sur vos produits numériques.

Product Vision Board NR

Le Product Vision Board, comme son nom l’indique, est un tableau qui formalise la vision d’un produit, en développant plusieurs axes complétant cette vision : population cible, besoins et solutions, mesures.

Voici une version qui intègre l’angle du Numérique Responsable.

Source du format graphique : https://canva.link/mzfy2ljskdvlaxd

DOR/DOD x RGESN

Les DOR (Definition Of Ready) et DOD (Definition Of Done) sont deux éléments nécessaires pour cadrer votre workflow et optimiser la réalisation dans une équipe.

Si vous ne connaissez pas, voici deux ressources pour pallier cela. DOR Kards & DOD Kards.

J’aime beaucoup ces checklists qui peuvent aider les équipes, sauf que je trouve qu’elles sont généralement très orientées et sont poussiéreuses par rapport au Numérique Responsable.

Le RGESN est le Référentiel général d’écoconception de services numériques. C’est un ensemble de règles à respecter dans une démarche d’écoconception.

J’ai décidé de prendre deux éléments et de les fusionner pour qu’une équipe puisse embarquer les bonnes pratiques de l’écoconception directement dans son mode de fonctionnement.

Ces critères intègrent les bonnes pratiques d’écoconception, tout en restant alignées sur les 3U (utiles, utilisables, utilisés).

? Definition of Ready NR (DoR)

Une user story ou une tâche est considérée comme « prête » si elle respecte les critères suivants :

1. Utilité et Pertinence (RGESN – Critère 1.1)

• La user story répond à un besoin réel et validé (études utilisateurs, personas, ou feedbacks).
• Elle est alignée avec au moins un Objectif de Développement Durable (ODD) ou une limite planétaire (ex. : réduction des émissions de CO?).
• Une analyse d’impact a été réalisée pour vérifier que la fonctionnalité crée plus de valeur qu’elle n’en détruit (ex. : gain utilisateur vs coût environnemental).
• On a vérifié qu’aucune solution existante (interne ou externe) ne répond déjà à ce besoin.

2. Cibles et Besoins (RGESN – Critère 1.2)

• Les utilisateurs cibles (primaires et secondaires) sont clairement définis.
• Les attentes et contraintes des utilisateurs sont documentées (ex. : accessibilité, performance).
• La user story est priorisée en fonction de son ratio impact/ressource (ex. : méthode MoSCoW ou YAGNI).

3. Contraintes Techniques et Environnementales

• Les contraintes techniques (ex. : compatibilité avec des appareils anciens) sont identifiées.
• Les contraintes environnementales sont prises en compte :
  • Poids maximal de la fonctionnalité (ex. : < 500 Ko pour une page web).
  • Temps de chargement cible (ex. : < 1 s).
  • Hébergement vert confirmé (data center alimenté par énergies renouvelables).
• Les données nécessaires sont minimisées (RGPD + écoconception).

4. Critères d’Acceptation
   • Les critères d’acceptation incluent des métriques environnementales (ex. : score EcoIndex > 80/100).
   • Les critères d’accessibilité sont définis (ex. : respect des WCAG 2.2).
   • Les tests de performance (ex. : temps de réponse, consommation énergétique) sont planifiés.

? Definition of Done NR (DoD)

Une user story ou une tâche est considérée comme « terminée » si elle respecte les critères suivants :

1. Fonctionnalité et Utilité

• La fonctionnalité est implémentée et testée selon les critères d’acceptation.
• Elle répond strictement au besoin sans ajouter de fonctionnalités inutiles (principe YAGNI).
• Elle est documentée (pour les utilisateurs et les développeurs).

2. Écoconception (RGESN – Critères Techniques)

• Poids et performance :
  • Le poids de la fonctionnalité est ? au seuil défini (ex. : < 500 Ko).
  • Le temps de chargement est ? à la cible (ex. : < 1 s).
• Efficacité énergétique. :
  • Le code est optimisé (pas de libraries inutiles, algorithmes légers).
  • Les requêtes serveurs sont minimisées (ex. : lazy loading, cache).
• Hébergement :
  • La fonctionnalité est déployée sur une infrastructure verte (data center alimenté par énergies renouvelables).

3. Accessibilité et Inclusivité

• La fonctionnalité respecte les normes WCAG 2.2 (niveau AA minimum).
• Elle est testée sur des appareils anciens (ex. : smartphones 5 ans, navigateurs non récents).
• Elle est compatible avec les technologies d’assistance (ex. : lecteurs d’écran).

4. Données et RGPD

• Minimisation des données :
  • Seules les données strictement nécessaires sont collectées.
  • Les données sont stockées le moins longtemps possible.
• Transparence :
  • Les utilisateurs sont informés de la collecte et de l’usage des données.
  • Un mécanisme de consentement explicite est en place (opt-in).

5. Mesure d’Impact

• L’empreinte environnementale de la fonctionnalité a été évaluée (ex. : score EcoIndex, ACV simplifiée).
• Les métriques de performance (ex. : temps de réponse, consommation CPU) sont documentées.
• Les améliorations possibles pour réduire l’impact sont identifiées et priorisées.

6. Documentation et Transparence

• La fonctionnalité est documentée dans le backlog ou le wiki de l’équipe.
• Une déclaration d’écoconception est mise à jour (si applicable).
• Les choix techniques (ex. : pourquoi un algorithme plutôt qu’un autre) sont justifiés.

7. Revue et Validation
   • La fonctionnalité a été revue par l’équipe (code review, tests utilisateurs).
   • Elle a été validée par le Product Owner et le référent écoconception (si applicable).
   • Les feedbacks utilisateurs (si disponibles) sont pris en compte.

Vous pouvez retrouver la version graphique complète ici : https://canva.link/lbgfcl0loax2dzb

Il existe beaucoup d’autres choses à faire pour intégrer le Numérique Responsable dans votre organisation.

Si vous désirez aller plus loin, contactez-nous pour discuter d’une formation complète autour du Product Management Responsable.

On en parle ?

Johan

Source picto & photos (image d’entête) : https://thenounproject.com/

Two unrecognizable female students holding handmade globe world earth by David Pereiras from https://thenounproject.com/photo/two-unrecognizable-female-students-holding-handmade-globe-world-earth-499VOE (CC BY-NC-ND 2.0)

L’article Ajoutez du Numérique Responsable dans votre Product Management est apparu en premier sur EKITE.