Impact
Engagement — comprendre et agir
Synthèse pratique du concept d'engagement (source Philonomist) et lien avec la cartographie des paris du blog pour agir en atelier.
Philonomist propose ce dernier mois un test sur l’engagement. L’occasion pour moi
- d’approfondir cette notion à la mémoire de mes derniers accompagnements en coaching d’organisation,
- de me rappeler de la place accordée à l’engagement dans l’agilité, notamment en lien avec la valeur de courage, et la façon dont on définit et respecte les objectifs)
- de le relier à mes articles précédents
- de safisfaire ma curiosité (et rentabiliser mon abonnement) en revisitant le site Philonomist et (re)découvrant quelques articles toujours intéressants, par leur questionnement sur le monde de l’entreprise.
- enfin d’imaginer un atelier, selon mon inspiration du moment que je puisse sortir si l’occasion se présente.
Ceci écrit, voilà déjà une forme d’engagement que d’établir une liste d’actions et de critères qui font sens pour obtenir un résultat.
🔧 Audit & Améliorations Écoconception 2025
Audit d'écoconception du site Hugo - Recommandations basées sur GR491 (INR) et outils Lighthouse/Kastor.green. Plan d'action pour réduire l'empreinte numérique.
🎯 Objectif: Réduire l’Empreinte Numérique du Site
Cet audit vise à identifier les gisements d’économie d’énergie et de ressources sur le site Hugo, en s’appuyant sur les pratiques GR491 de l’Institut du Numérique Responsable (INR).
🛠️ Outils d’Audit Utilisés
| Outil | Utilité | Points forts |
|---|---|---|
| Lighthouse | Performance, accessibilité, bonnes pratiques | Scores détaillés, recommandations prioritaires |
| Kastor.green | Analyse d’empreinte carbone numérique | Liens direct vers RGESN et GR491 de l’INR |
| Web Vitals | Métriques Core Web Vitals | Compression, temps de réponse |
📊 Améliorations Identifiées (Priorisées)
🔴 Critique (Impact > 200 Kib)
| Action | Gain Estimé | Pratique GR491 | Hugo Implementation |
|---|---|---|---|
| Activer compression Gzip/Brotli | 437 Kib | 1.1 - Réduire poids transféré | Config output.formats.HTML.mediaTypes |
| Éliminer CSS inutilisé | 260 Kib | 4.2 - Optimiser CSS | Utiliser PurgeCSS ou TailwindCSS avec purge |
| Réduire JavaScript inutilisé | 176 Kib | 2.1 - Minimiser ressources JS | Lazy loading, code splitting par section |
🟡 Important (50-200 Kib)
| Action | Gain Estimé | Pratique GR491 | Hugo Implementation |
|---|---|---|---|
| Images optimisées (WebP, dimensions) | ~150 Kib | 3.1 - Images responsives | Hugo image processing + formats multiples |
| Ajouter attributs width/height images | ~50 Kib | 3.2 - Éviter CLS | Front-matter YAML ou shortcodes |
| Diffuser avec cache HTTP efficace | Voir durée | 5.1 - Cache statique | Headers Cache-Control: max-age=31536000 |
🟢 Recommandé (< 50 Kib)
| Action | Gain Estimé | Pratique GR491 | Hugo Implementation |
|---|---|---|---|
| Ajouter print CSS | ~10 Kib | 1.3 - Média queries print | assets/css/print.css + @media print |
| Minifier HTML/JSON | ~20 Kib | 1.2 - Minification | Config Hugo minify.minifyOutput = true |
| Lazy loading iframes | ~5 Kib | 2.3 - Lazy loading | Attribut loading="lazy" sur iframes |
| Supprimer polyfills inutiles | ~15 Kib | 2.1 - Code mort | Audit bundle JS, vérifier support navigateurs |
🗺️ Mini-Guide Opératoire (Basé sur GR491)
Phase 1: Diagnostic Détaillé (GR491 Critère 1-2)
Objectif: Identifier consommation réelle avant/après
🤖 IA Responsable: Éthique, Risques et Gouvernance
Comprendre l'IA responsable - Enjeux de gouvernance, risques, et cadres de référence pour une IA plus humaine et durable.
🎯 L’IA Générative: Un Outil Qui Donne Le Vertige
L’intelligence artificielle générative s’est imposée en quelques mois comme un outil transformateur. Mais transformer vers quoi? Pour qui? Et à quel coût?
Bien que l’IA nous procure un sentiment d’omniscience avec la capacité de tout savoir sur tout en quelques prompts, il n’en reste pas moins des zones d’ombre.
Besoin De Hauteur de Vue
L’IA n’est pas neutre. Elle encode les choix, les biais, les valeurs de ceux qui l’ont créée. La question n’est pas “faut-il utiliser l’IA?” mais plutôt:
Pour un pragmatisme responsable
Cet article est inspiré par les conversations sur les fondamentaux et principes de l’organisation du travail que nous questionnons dans l’exercice de la fresque de l’agilité.
La question ici est de savoir si le pragmatisme est à la bonne place pour discuter de l’organisation des personnes en permettant de dépasser dans le management traditionnel ou moderne, les principes et les limites de la division du travail.
Nous entendons par management moderne, celui qui a pu incorporer une forme d’agilité avec les mêmes intentions que celles du management traditionnel.
Atelier Cartographie des Paris Produit
Design de l’atelier “Paris Produit” / “Product Bets”
Pourquoi un atelier ?
Les Product Bets ne sont pas un simple exercice académique. C’est un processus de collaboration intense entre :
- Les responsables produit
- Les leaders techniques
- Les sponsors métier
- Les stakeholders clés
L’Atelier Paris Produits
Cet atelier de 2 à 3 heures (6-20 participants) est structuré pour :
- Introduire le concept des Product Bets et leurs bénéfices
- Identifier collectivement les opportunités métier réelles
- Construire collaborativement les cartes de chaque pari (hypothèses, risques, ressources, métriques)
- Confronter les idées à travers des challenges croisés entre équipes
- Prioriser visuellement les paris selon leur valeur estimée vs. leur risque
- Capturer l’énergie et engager tous les participants dans l’ownership du résultat
Les 7 cartes en référence
L’atelier utilise 7 zones principales à renseigner pour structurer la réflexion sur chaque Product Bet :
Cartographie de Contexte : Visualiser l'Architecture Socio-Technique
Pourquoi la Cartographie de Contexte ?
La cartographie de contexte est une technique fondamentale du Domain-Driven Design (DDD) qui permet de visualiser les relations entre les contextes délimités (bounded contexts) et les équipes qui les gèrent. Elle répond à une problématique majeure en architecture logicielle : comment comprendre et gérer les dépendances dans un système complexe composé de multiples services ou modules ?
Le problème architectural traditionnel
En architecture logicielle, on observe souvent :
Cartographie des Paris Produits : De la Théorie à la Pratique
Pourquoi les “Product Bets” ?
En octobre 2025, James Shore a prononcé un discours majeur à la conférence Agile Cambridge intitulé “The Accountability Problem”. Ce discours adresse une problématique fondamentale que tout leader d’ingénierie connaît bien : comment démontrer l’accountability de l’équipe de développement logiciel ?
Le problème traditionnel
Généralement, les équipes de développement se voient imposer une forme d’accountability basée sur :
- Les fonctionnalités à livrer : “Pouvez-vous me promettre la feature X ?”
- Les dates : “Quand sera-ce terminé ?”
- La pression budgétaire : “Nous avons X dollars, combien de features cela nous achète-t-il ?”
Or, ce modèle repose sur une fausse prémisse : la croyance que le développement logiciel ressemble à faire un devoir scolaire - une tâche linéaire avec un début, une fin clairement définie, et un chemin prévisible de A à B.
Coaching
Cette section regroupe quelques réflexions personnelles sur le coaching. Pour préciser la perspective avec laquelle j’aborde le coaching dans ce blog, vous pouvez éventuellement commencer par un à propos de coaching
Expérimentations : Apprendre vite sur ses paris
Carte 7 : Itérations clés / Expériences
Définition
Lister les premières boucles d’apprentissage ou “build-measure-learn” à mener, avec une intention claire de valider rapidement les hypothèses du pari.
Exemples issus du terrain
Pour les “baby elephants”, James Shore propose une série d’expériences : tester l’appétence du marché, la logistique, la réceptivité via des versions pilotes ou des tests[attached_file:1].
Conseils
- Commencer par les risques clés (prioriser les tests qui pourraient “tuer” le pari)
- Privilégier les petits pas, retours rapides[web:8][web:3]
- Impliquer toute l’équipe et les parties prenantes[web:6]