Impact

Feedback

Le feedback est une des valeurs d’eXtreme Programming exprimée comme suit:

Nous prennons chaque engagement d’itération au sérieux en fournissant un logiciel fonctionnel. Nous faisons une démonstration précoce de notre logiciel, puis nous écoutons fréquemment et attentivement pour apporter les modifications nécessaires. Nous parlons du projet et adaptons notre processus à celui-ci, et non l’inverse.

En synthèse dans ce contexte d’une équipe de développement logiciel, il s’agit de solliciter et écouter fréquemment et attentivement “les parties prenantes” pour adapter la façon de faire en vue d’atteindre un objectif commun.

Coaching

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

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

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.

🎯Customiser l'Atelier de Cartographie: Adapter aux Types d'Équipes et Dépendances

Introduction

L’atelier de cartographie de contexte n’est pas “one-size-fits-all”. Selon la structure organisationnelle actuelle, les types de dépendances en place, et les patterns existants, vous devrez adapter le design de facilitation pour être pertinent et actionnable.

Ce guide vous aide à customiser l’atelier en fonction de votre situation réelle.

Partie 1: Diagnostiquer Votre Situation Actuelle

Étape 1.1: Identifier les Types d’Équipes Présentes

Avant l’atelier, cartographiez rapidement:

Pour chaque paire d'équipes, demandez-vous:

A et B dépendent-elles l'une de l'autre?
├─ NON, zéro dépendance
│  └─ Type: INDEPENDENT TEAMS
│
└─ OUI, il y a dépendance
   ├─ C'est mutuel (A dépend de B, B dépend de A)?
   │  └─ Type: MUTUALLY DEPENDENT TEAMS
   │
   └─ C'est asymétrique (A dépend de B, mais pas l'inverse)?
      └─ Type: UPSTREAM/DOWNSTREAM TEAMS

Étape 1.2: Inventorier les Patterns Actuels

Pour chaque relation identifiée, diagnostiquez le pattern en place:

📇 Carte Context Mapping #11 : Upstream/Downstream Teams (Team Relationship)

Vue Rapide

🎯 Objectif : Une équipe fournit services à l’autre - asymétrique

💼 Type de relation : Hiérarchie implicite (qui dépend de qui?)

🔗 Nature : Dépendance unilatérale

Concept

Une équipe upstream fournit services à une ou plusieurs équipes downstream.

Upstream Team
    ↓ (provides services)
    ↓
Downstream Team(s)

Les caractéristiques:

  • ✓ Upstream ne dépend PAS du downstream
  • ✓ Downstream dépend d’Upstream
  • ✓ Asymétrique et clair

Différentes Configurations

1. One Upstream, One Downstream

Payment Service (Upstream)
    ↓
Order Service (Downstream)

Payment peut évoluer indépendamment.
Order attend Payment.

2. One Upstream, Many Downstream

Product Catalog (Upstream)
    ↓ ↓ ↓ ↓ ↓
Pricing | Inventory | Search | Recommendation | Analytics
(Downstream services)

Catalog ne connaît pas ses utilisateurs.
Tous dépendent de Catalog.

3. Tiered Upstream/Downstream

Infrastructure (Upstream 1)
    ↓
Core Platform (Upstream 2)
    ↓
Business Services (Downstream)

Patterns Possibles dans Upstream/Downstream

Selon la relation, différents patterns:

📇 Carte Context Mapping #12 : Independent Teams (Team Relationship)

Vue Rapide

🎯 Objectif : Deux équipes opèrent indépendamment, zéro dépendance

💼 Type de relation : Aucune (autonome complète)

🔗 Nature : Parallèle, zéro couplage

Concept

Deux équipes qui peuvent progresser complètement indépendamment sans se bloquer.

Team A        Team B
(indépendant) (indépendant)
     ↓ ↓ ↓ ↓ ↓ ↓
    (Zéro couplage)

Caractéristiques

Ce qui les Définit

  • ✓ Zéro dépendances : l’une peut évoluer sans l’autre
  • ✓ Contextes distincts : domaines totalement séparés
  • ✓ Données indépendantes : si partage, c’est via batch/events
  • ✓ Autonomie complète : aucune coordination requise

Ce qui les Différencie des Autres

VS. Upstream/Downstream:
  → Upstream/Downstream = dépendance
  → Independent = zéro dépendance

VS. Mutually Dependent:
  → Mutually Dependent = interdépendance
  → Independent = complètement libres

Idéal dans Microservices

Architecture

Service A (Independent)
├─ Own code
├─ Own database
├─ Own API
└─ Owns its fate

Service B (Independent)
├─ Own code
├─ Own database
├─ Own API
└─ Owns its fate

Coordination: Minimal (maybe async events)

Implications Organisationnelles

Avantages

  • ✓ Complète autonomie : pas d’attendre l’autre
  • ✓ Vitesse : chacun va à son rythme
  • ✓ Ownership : claire et motivante
  • ✓ Scaling : ajoute équipes sans syncro
  • ✓ Failure isolation : équipe A crash pas équipe B

Challenges

  • ⚠️ Duplication : chacun implémente sa version
  • ⚠️ Incohérence : les deux ont des approches différentes
  • ⚠️ Outils différents : pas d’unification possible
  • ⚠️ Learning silos : pas de partage de connaissance
  • ⚠️ Onboarding : chacun a sa culture

Communication: Quand Nécessaire

Pattern 1: Asynchronous Events

Team A does something
    ↓
Publishes event (OrderPlaced)
    ↓
Team B picks it up (async)
    ↓
No blocking, no real-time sync

Pattern 2: Read-Only Access

Team A owns data
Team B reads it (if needed)
    ↓
No writes between them
    ↓
Team B can lag behind

Pattern 3: Batch Sync

Team A exports data nightly
    ↓
Team B imports nightly
    ↓
Updates 24h later
    ↓
Acceptable delay

Pattern 4: Complete Separation

Team A: doesn't know B exists
Team B: doesn't know A exists
    ↓
Zero communication

Exemples du Monde Réel

SaaS Platform

Auth Team
├─ Handles user login/security
├─ Owns user DB
└─ Exposes API

Reporting Team
├─ Handles analytics/reports
├─ Owns analytics DB
├─ Reads user data (read-only)
└─ Zero coordination needed

Content Team
├─ Manages blog/docs
├─ Owns content DB
└─ Completely separate

E-commerce

Order Service Team
├─ Orders only
├─ Can scale independently
└─ Publishes OrderPlaced events

Inventory Service Team
├─ Inventory only
├─ Listens to OrderPlaced
├─ Decrements stock asynchronously
└─ No blocking dependency

Analytics Team
├─ Reads events (Order, Inventory)
├─ Processes asynchronously
└─ No impact on live systems

Governance

Decision Making

Team A decides its direction → Done
Team B decides its direction → Done
No vetoes, no blocking

Shared Resources?

If need shared infrastructure:
  → Infrastructure team is independent too
  → Or dedicated team owns it
  → But integration still async/event-based

Conflicts

Conflict between teams?
  → Each goes its own way
  → Or escalate to higher-level alignment

Trade-offs

When It’s Perfect

✓ Service A: Payments
✓ Service B: Marketing/Email
✓ Service C: Analytics

→ These can be completely independent
→ Perfect microservices setup

When It’s Not Possible

✗ Frontend & Backend of same product
  → Too coupled, need Partnership or Shared Kernel

✗ Inventory & Orders
  → Need synchronization, not truly independent

✗ Core Platform & Applications
  → Core is needed by apps, Upstream/Downstream better

Cost Analysis

Infrastructure

Benefit: Can scale each independently
Cost: More infrastructure, more databases
Trade-off: Worth it for high-scale systems

Development

Benefit: Teams move fast, no waiting
Cost: Potential duplication, less sharing
Trade-off: Speed > DRY principle (in microservices)

Operational

Benefit: Failure isolated
Cost: More systems to monitor
Trade-off: Worth it for reliability

Indicators

Independence Healthy ✅

✓ Teams deploy independently
✓ No blocking on each other
✓ Different tech stacks OK
✓ Minimal communication meetings
✓ Each owns their metrics

Independence Problematic ❌

❌ Frequent cross-team meetings
❌ Waiting on each other
❌ Duplication becoming costly
❌ Incohesive systems
❌ Can't deploy independently

When to Choose Independence

Right Fit

  • Small, focused services
  • High-scale systems
  • Different business domains
  • Different maturity levels
  • Different technology choices needed

Wrong Fit

  • Tightly coupled features
  • Need real-time consistency
  • Shared data models
  • Young team (need learning)
  • Not enough scale to justify overhead

Checklist per Independent Teams ✓

  • Completely separate code/data/deployment
  • Communication plan (events, async, batch)
  • Monitoring of each service independently
  • Failure scenarios handled independently
  • No hidden dependencies (audit for coupling)
  • Teams feel autonomous (survey culture)

Transitioning to Independence

From Dependent to Independent

Mutually Dependent
    ↓ (too slow)
Try Partner → Still coupled
    ↓
Extract: one becomes independent
    → Shared Kernel of critical shared data only
    → Events for everything else
    → Now mostly Independent

From Monolith to Independent

Monolith (all one team)
    ↓ (slow to scale)
Strangler Pattern:
    ├─ Extract Service A
    ├─ Service A becomes Independent
    ├─ Extract Service B
    ├─ Service B becomes Independent
    ├─ ...repeat...
    └─ Monolith eventually sunset

Ressources

  • Building Microservices par Sam Newman - Team Topology
  • Team Topologies par Matthew Skelton - X-as-a-Service
  • Release It! par Michael Nygard - Microservice Coordination
  • DDD Crew - Context Mapping

Notes de Facilitation pour l’Atelier

Animation

  • Demandez : “Êtes-vous vraiment indépendants ?”
  • Testez : “Qu’arrive-t-il si Service X casse ?”
  • Documentez : “Quelles sont vos vraies dépendances ?”

Pièges Communs

  • ⚠️ Dépendances cachées : “Pensaient-ils être indépendants, mais…”
  • ⚠️ Trop de duplication : coûteux à maintenir
  • ⚠️ Inconsistences : données divergent
  • ⚠️ Organisation tue architecture : réorgé casse l’indépendance

Questions Provocatrices

  • “Si je change Service A, affecte-t-ça Service B ?”
  • “Combien de personnes doivent se synchroniser ?”
  • “Est-ce vraiment de l’indépendance ou du chaos ?”
  • “Pourriez-vous déployer Service A sans toucher Service B ?”