Gérer les conflits et situations critiques

Objectif : Naviguer dans les moments difficiles

Bon, on arrive au chapitre que personne n’aime lire mais que tout le monde devrait maîtriser. Parce que oui, même avec la meilleure équipe du monde, la culture la plus saine et les processus les plus rodés, il y aura des conflits, des crises, et des moments où tout part en vrille.

Et là, surprise : c’est quand ça va mal qu’on reconnaît les vrais leaders. N’importe qui peut manager quand tout va bien. Mais quand le serveur de prod explose un vendredi soir, qu’il y a une fuite de données, ou que deux développeurs seniors se tapent dessus, c’est là que votre valeur de CTO se révèle.

Identifier et désamorcer les conflits techniques

Les types de conflits techniques

Tous les conflits ne se ressemblent pas. Comprendre le type de conflit vous aide à choisir la bonne approche.

1. Conflit de vision architecturale “On devrait faire du microservices !” vs “Le monolithe suffit largement !”

Causes :

• Niveaux d’expérience différents
• Contextes précédents différents
• Ego et volonté de briller

2. Conflit de priorités “Il faut d’abord refactoriser” vs “Il faut livrer la feature”

Causes :

• Pression business vs qualité technique
• Vision court terme vs long terme
• Compréhension différente des enjeux

3. Conflit de standards “On code comme ça” vs “Non, on code comme ça”

Causes :

• Habitudes d’équipes différentes
• Absence de standards clairs
• Résistance au changement

4. Conflit de responsabilités “C’est pas mon module” vs “C’est pas le mien non plus”

Causes :

• Ownership mal défini
• Silos techniques
• Peur de la responsabilité

Détecter les conflits avant qu’ils explosent

Signaux faibles à surveiller :

Dans les interactions :

• Échanges courts et formels entre certaines personnes
• Évitement des sujets techniques sensibles
• Remarques sarcastiques en code review
• Absence de collaboration sur les projets communs

Dans le code :

• PRs qui traînent sans feedback constructif
• Contournement des standards par certains développeurs
• Duplication de code au lieu de réutilisation
• Commentaires passifs-agressifs dans le code

Dans les process :

• Boycott discret de certains rituels
• Décisions techniques prises en parallèle
• Escalade systématique vers vous
• Réunions techniques qui tournent en débat stérile

Mon expérience chez Hiveo : J’ai mis 1 mois à réaliser que nos deux tech leads ne se parlaient plus à cause de désaccords sur des sujets d’implémentations. Le signal ? Ils ne faisaient plus jamais de code review croisée.

Techniques de médiation

Étape 1 : Écouter individuellement

Avant toute médiation collective, comprenez le point de vue de chacun.

Questions à poser :

• Peux-tu m’expliquer ton point de vue ?
• Qu’est-ce qui te fait dire ça ?
• Quels sont tes objectifs dans cette situation ?
• Qu’est-ce qui te dérangerait le plus dans la solution adverse ?
• Comment on pourrait avancer ensemble ?

Étape 2 : Identifier les intérêts communs

La plupart du temps, les parties ont plus d’intérêts communs qu’elles ne le pensent.

Intérêts communs typiques :

• Livrer un produit de qualité
• Maintenir la vélocité de l’équipe
• Éviter la dette technique
• Garder une architecture maintenable
• Respecter les délais

Étape 3 : Médiation structurée

Format de réunion (1h max) :

10 min - Cadrage

• Rappel des règles : respect, écoute, focus sur les faits
• Objectif : trouver une solution qui marche pour tout le monde
• Pas de recherche de coupable

20 min - Expression des positions

• Chaque partie expose son point de vue (5 min max chacune)
• Pas d’interruption, pas de jugement
• Questions de clarification uniquement

20 min - Recherche de solutions

• Brainstorming collectif
• Toutes les idées sont bonnes à prendre
• Focus sur les intérêts communs identifiés

10 min - Accord et suivi

• Choix de la solution
• Plan d’action avec responsabilités
• Point de suivi dans 1-2 semaines

Exemple de résolution :

Conflit entre Paul (backend, pro-microservices) et Marie (frontend, pro-monolithe).

Positions :

• Paul : “Il faut découpler pour scaler”
• Marie : “Ça va complexifier le développement frontend”

Intérêts communs identifiés :

• Maintenir la vélocité de développement
• Préparer la montée en charge
• Garder une architecture compréhensible

Solution trouvée : Migration progressive : on commence par extraire le module de facturation (identifié comme bottleneck), on mesure l’impact sur la vélocité, puis on décide pour la suite.

Gestion de crise technique

Les types de crises techniques

Crise de disponibilité

• Panne générale du service
• Dégradation de performance
• Indisponibilité partielle

Crise de sécurité

• Faille de sécurité découverte
• Tentative d’intrusion
• Fuite de données

Crise de données

• Corruption de base de données
• Perte de données
• Incohérence des données

Crise de déploiement

• Déploiement qui casse tout
• Rollback impossible
• Dependencies cassées

Le plan de gestion de crise

Phase 1 : Détection et alerte (0-5 minutes)

Objectifs :

• Confirmer l’incident
• Évaluer l’ampleur
• Alerter les bonnes personnes

Actions :

• Vérifier les alertes automatiques
• Confirmer l’impact utilisateur
• Déclencher la cellule de crise
• Ouvrir un canal de communication dédié

Phase 2 : Évaluation et communication (5-15 minutes)

Objectifs :

• Comprendre la cause probable
• Communiquer en interne et externe
• Organiser la résolution

Actions :

• Assessment rapide de la situation
• Communication aux stakeholders
• Assignation des rôles dans l’équipe
• Mise en place du status page

Phase 3 : Résolution (15 minutes - X heures)

Objectifs :

• Restaurer le service
• Minimiser l’impact
• Documenter les actions

Actions :

• Implémentation du fix ou rollback
• Tests et validation
• Communication des avancées
• Monitoring renforcé

Phase 4 : Post-incident (24-48h après)

Objectifs :

• Comprendre la cause racine
• Définir les actions d’amélioration
• Communiquer les learnings

Actions :

• Post-mortem bienveillant
• Plan d’action d’amélioration
• Communication finale
• Mise à jour des process

Organiser l’équipe en crise

Les rôles clés :

Incident Commander (le CTO ou son délégué)

• Prend les décisions finales
• Coordonne les équipes
• Communique avec le management
• Garde la vision d’ensemble

Technical Lead

• Investigate la cause technique
• Propose et implémente les solutions
• Coordonne les développeurs
• Valide les fixes

Communication Lead

• Gère la communication externe (clients, public)
• Rédige les status updates
• Interface avec le support client
• Prépare les comms post-incident

Documentation Lead

• Documente tout ce qui se passe
• Maintient la timeline des événements
• Prépare les éléments pour le post-mortem
• Archive les décisions prises

Communication de crise

Interne - Canal de crise (Slack/Teams)

Framework de communication de crise structurée :

Princi0pes de communication d’incident :

1. Communication interne (première alerte) :

• Clarté : Impact décrit en termes business, pas techniques
• Assignation : Rôles et responsabilités clairs dès le départ
• Timeline : Engagement sur les points de suivi réguliers
• Escalade : Critères clairs pour alerter le management

2. Communication externe (clients/public) :

• Transparence : Reconnaissance rapide du problème
• Empathie : Compréhension de l’impact sur les utilisateurs
• Action : Équipe mobilisée, travail en cours
• Engagement : Timeline réaliste pour les mises à jour

Questions stratégiques pour votre framework :

• Quels canaux privilégier selon la sévérité ?
• Comment adapter le message selon l’audience ?
• Quel niveau de détail technique partager ?
• Comment éviter la sur-communication qui noie l’information ?

Outils et processus à mettre en place :

• Status page automatisée avec intégrations monitoring
• Templates pré-écrits pour les scénarios fréquents
• Chaînes d’escalade définies avec seuils clairs
• Formation équipe sur les techniques de communication de crise

Règles de communication :

• Fréquence régulière (toutes les 30 min minimum)
• Honnêteté sur ce qu’on sait et ne sait pas
• Pas de promesse qu’on ne peut pas tenir
• Timeline réaliste pour la résolution

Gérer les situations RH difficiles

Performance insuffisante

Signaux d’alarme :

• Baisse de qualité du code répétée
• Non-respect des deadlines récurrent
• Désengagement visible
• Feedback négatif de l’équipe

Approche en 3 étapes :

Étape 1 : Discussion informelle

• 1-on-1 pour comprendre la situation
• Identification des causes (personnelles, techniques, organisationnelles)
• Proposition d’aide et de soutien
• Fixation d’objectifs d’amélioration

Étape 2 : Plan d’amélioration formel

• Objectifs SMART avec timeline (généralement 3 mois)
• Points de contrôle réguliers (bi-hebdomadaires)
• Ressources et soutien alloués (formation, mentoring)
• Conséquences claires en cas de non-amélioration

Étape 3 : Décision finale

• Évaluation objective de l’amélioration
• Soit continuation avec nouvelles responsabilités
• Soit changement de poste (si possible)
• Soit séparation à l’amiable

Framework de plan d’amélioration des performances :

Méthodologie structurée pour la remédiation :

1. Diagnostic précis des causes :

• Compétences techniques : Gaps identifiés vs niveau requis
• Facteurs organisationnels : Processus, outils, environnement
• Motivation personnelle : Alignement avec objectifs carrière
• Circonstances extérieures : Problèmes personnels, charge de travail

2. Objectifs SMART et mesurables :

• Spécifiques : Comportements/résultats précis attendus
• Mesurables : Métriques objectives (qualité, délais, satisfaction)
• Atteignables : Réalistes compte tenu du contexte
• Temporalisés : Échéances claires avec points de contrôle

3. Support adapté au profil :

• Formation technique : Selon les gaps identifiés
• Mentoring : Pairing avec un développeur expérimenté
• Ajustement organisationnel : Charge, outils, processus
• Suivi rapproché : Fréquence adaptée à la situation

4. Critères de succès et conséquences :

• Métriques de progression : Indicateurs intermdiaires
• Scénarios de réussite : Nouvelles responsabilités, reconnaissance
• Plan B : Alternatives si amélioration insuffisante
• Décision finale : Critères objectifs pour continuation/séparation

Questions clés pour le CTO :

• L’investissement en temps/ressources est-il justifié ?
• L’équipe peut-elle supporter cette période d’amélioration ?
• Les causes sont-elles réellement corrigeables ?
• Quel message cela envoie-t-il au reste de l’équipe ?

Comportements toxiques

Types de comportements toxiques :

L’égo sur-dimensionné

• Techniquement excellent mais impossible à vivre
• Critique tout le monde, accepte aucune critique
• Crée un climat de peur dans l’équipe

Le saboteur passif

• Résistance discrète aux décisions
• Rumeurs et critiques en sous-main
• Non-respect des standards “par accident”

Le hero complex

• Veut tout faire tout seul
• Ne documente rien
• Créé des dépendances critiques

Approche de gestion :

1. Documentation rigoureuse

• Incidents comportementaux datés et factualisés
• Témoignages de collègues impactés
• Impact mesurable sur l’équipe/projets

2. Confrontation directe

• Feedback clair et non-ambigü
• Conséquences explicites
• Timeline de changement requis

3. Isolation si nécessaire

• Retrait des responsabilités critiques
• Limitation des interactions toxiques
• Préparation de la sortie

Exemple de confrontation :

“Paul, on doit parler de ton comportement en code review. Cette semaine, tu as refusé 3 PRs avec des commentaires comme ‘ce code est nul’ sans explication constructive. Marie et Sophie m’ont dit qu’elles n’osent plus soumettre de code. Ce comportement doit changer immédiatement. À partir de maintenant, tout feedback négatif doit être accompagné d’une suggestion constructive. Si ça se reproduit, on parlera de conséquences plus lourdes.”

Burn-out et problèmes personnels

Détecter le burn-out :

• Changement de comportement soudain
• Baisse de qualité du travail
• Absentéisme ou présentéisme excessif
• Irritabilité inhabituelle
• Isolement de l’équipe

Approche de soutien :

1. Conversation privée et bienveillante

"Sarah, j'ai remarqué que tu sembles fatiguée ces derniers temps.
Comment tu te sens ? Y a-t-il quelque chose avec lequel je peux t'aider ?"

2. Ajustement temporaire de la charge

• Redistribution des tâches urgentes
• Réduction des responsabilités non-critiques
• Encouragement à prendre des congés

3. Ressources et soutien

• Accompagnement médical si nécessaire
• Aménagement du temps de travail
• Support psychologique via la mutuelle
• Environnement de travail adapté

4. Retour progressif

• Plan de retour en douceur
• Monitoring de la charge de travail
• Éviter la rechute

Gérer la pression et le stress d’équipe

Sources de stress en équipe technique

Stress technique :

• Bugs critiques récurrents
• Dette technique qui s’accumule
• Technologies obsolètes ou mal maîtrisées
• Architecture complexe et fragile

Stress organisationnel :

• Deadlines irréalistes
• Changements de priorités fréquents
• Manque de visibilité sur la roadmap
• Processus lourds et inefficaces

Stress relationnel :

• Conflits dans l’équipe
• Management toxique
• Manque de reconnaissance
• Isolation ou exclusion

Stress externe :

• Pression des clients/utilisateurs
• Concurrence agressive
• Conjoncture économique
• Problèmes personnels

Techniques de gestion du stress collectif

1. Transparence et communication

Information régulière :

• Pourquoi on fait ce qu’on fait
• Où en est l’entreprise
• Quels sont les vrais enjeux
• Comment l’équipe contribue au succès

Exemple de communication transparente : “L’équipe, on a un gros challenge devant nous. Le client X veut sa feature dans 6 semaines au lieu de 10. C’est tendu mais faisable si on se concentre sur l’essentiel. Voici ce qu’on va faire : on reporte les features Y et Z, on simplifie l’approche technique, et on met Paul en renfort. Questions ?”

2. Réduction des facteurs de stress

Actions concrètes :

• Améliorer la stabilité technique (monitoring, tests)
• Simplifier les processus bureaucratiques
• Clarifier les responsabilités de chacun
• Mettre en place des garde-fous (code review, pair programming)

3. Renforcement de la cohésion

Activités team building :

• Sessions de résolution de problèmes collectifs
• Retrospectives approfondies
• Sorties informelles (laser game, escape game)
• Formations communes

Rituels de décompression :

• Vendredi soir débrief avec une bière
• Pause café quotidienne commune
• Celebration des succès (même petits)
• Moments de détente (babyfoot, jeux vidéo)

Gérer sa propre charge émotionnelle

En tant que CTO, vous êtes souvent la personne vers qui tout le monde se tourne quand ça va mal. Il faut savoir gérer votre propre stress pour être efficace.

Techniques personnelles :

1. Délégation et responsabilisation

• Former des lieutenants capables de gérer en votre absence
• Responsabiliser l’équipe sur la résolution de problèmes
• Éviter le syndrome du sauveur

2. Prise de recul régulière

• Moments de réflexion quotidiens (15 min)
• Marche ou sport pour décompresser
• Discussion avec d’autres CTOs (réseau)
• Coaching ou accompagnement externe

3. Priorisation impitoyable

• Focus sur ce qui a vraiment de l’impact
• Dire non aux urgences non-critiques
• Déléguer les sujets non-stratégiques

4. Séparation vie pro/vie perso

• Horaires de travail respectés
• Déconnexion numérique le soir/weekend
• Hobbies et activités externes
• Relations sociales hors travail

Techniques de communication en situation difficile

La communication non-violente (CNV)

Particulièrement utile dans les conflits et situations tendues.

Les 4 étapes de la CNV :

1. Observation factuelle (sans jugement) ❌ “Tu n’écoutes jamais” ✅ “En réunion hier, tu as regardé ton phone 5 fois pendant que Paul présentait”

2. Expression du sentiment ❌ “Tu m’énerves” ✅ “Je me sens frustré quand j’ai l’impression que l’équipe n’est pas attentive”

3. Expression du besoin ❌ “Tu dois mieux écouter” ✅ “J’ai besoin que nos réunions soient productives et que chacun se sente écouté”

4. Demande concrète ❌ “Arrête de faire ça” ✅ “Est-ce que tu peux laisser ton phone en mode avion pendant nos réunions d’équipe ?”

Gestion des émotions fortes

Quand l’autre est en colère :

1. Laisser l’émotion s’exprimer

• Ne pas couper ou minimiser
• Écouter activement
• Reformuler pour montrer qu’on a compris

2. Reconnaître l’émotion “Je vois que tu es vraiment en colère/frustré/inquiet.”

3. Chercher les faits derrière l’émotion “Qu’est-ce qui s’est passé exactement ?” “Qu’est-ce qui te préoccupe le plus ?”

4. Proposer des solutions “Comment on peut résoudre ça ensemble ?”

Exemple de gestion d’émotion forte :

Marie arrive en furie : “Ce projet est n’importe quoi ! On n’arrête pas de changer les specs, Paul fait n’importe quoi avec l’architecture, et personne ne m’écoute !”

Réponse CNV : “Marie, je vois que tu es vraiment frustrée. Assieds-toi, raconte-moi exactement ce qui s’est passé. [Écoute active] Effectivement, je comprends que ces changements répétés soient difficiles à gérer. J’ai besoin qu’on trouve une solution qui marche pour toi et pour l’équipe. Est-ce qu’on peut clarifier les specs ensemble et établir un process pour les changements futurs ?”

Communication de décisions difficiles

Parfois, en tant que CTO, vous devez prendre des décisions que l’équipe n’aimera pas.

Framework de communication :

1. Contexte et enjeux Expliquez pourquoi cette décision est nécessaire. “La situation actuelle est…” “Les enjeux sont…”

2. Décision et rationale Annoncez clairement la décision et pourquoi vous l’avez prise. “J’ai décidé de…” “Parce que…”

3. Impact et support Reconnaissez l’impact sur l’équipe et proposez du soutien. “Je sais que ça va impacter…” “Voici comment on va vous accompagner…”

4. Questions et feedback Ouvrez la discussion tout en maintenant la décision. “Je comprends que vous ayez des questions…” “Votre feedback est important pour l’implémentation…”

Exemple - Décision de migration technologique forcée :

“L’équipe, on doit parler d’une décision importante. Notre framework actuel ne sera plus supporté dans 12 mois, et nos clients nous demandent des features qu’on ne peut pas livrer avec la stack actuelle. J’ai décidé qu’on va migrer vers React/Node.js dans les 6 prochains mois. Je sais que certains d’entre vous préfèrent notre stack actuelle et que la migration va demander un effort d’apprentissage. On va organiser des formations, du pair programming, et prendre le temps nécessaire. Mais cette décision n’est pas négociable. Par contre, comment on l’implémente, ça on en discute ensemble.”

Outils et templates pour la gestion de crise

Runbook de gestion d’incident

# Runbook - Gestion d'Incident Majeur

## Définition d'un incident majeur
- [ ] Service principal indisponible > 15 minutes
- [ ] Perte de données client
- [ ] Faille de sécurité confirmée
- [ ] Impact sur > 50% des utilisateurs

## Phase 1 - Détection (0-5 min)
- [ ] Confirmer l'incident via monitoring
- [ ] Évaluer l'impact utilisateur
- [ ] Créer le channel Slack #incident-[date]
- [ ] Alerter l'Incident Commander
- [ ] Ouvrir le status page

## Phase 2 - Organisation (5-15 min)
- [ ] Incident Commander prend la main
- [ ] Assigner les rôles (Tech Lead, Communication, Documentation)
- [ ] Premier point de situation interne
- [ ] Communication externe initiale
- [ ] Escalade au management si nécessaire

## Phase 3 - Résolution (15min - X heures)
- [ ] Investigation technique en parallèle
- [ ] Tests de hypothèses de fix
- [ ] Implémentation de la solution
- [ ] Validation du retour à la normale
- [ ] Communication de résolution

## Phase 4 - Post-Incident (24-48h)
- [ ] Post-mortem scheduling (dans les 24h)
- [ ] Documentation complète de l'incident
- [ ] Communication finale aux clients
- [ ] Plan d'action d'amélioration
- [ ] Suivi des actions (30 jours)

## Contacts d'urgence
- Incident Commander: [Nom] - [Téléphone]
- CTO: [Nom] - [Téléphone]
- Ops Lead: [Nom] - [Téléphone]
- CEO: [Nom] - [Téléphone]

## Templates de communication
Voir templates séparés pour:
- Communication interne (Slack)
- Status page updates
- Email clients
- Post-mortem report

Template de post-mortem

# Post-Mortem - [Titre de l'incident]

## Résumé exécutif
**Date:** [Date et heure]
**Durée:** [Durée totale]
**Impact:** [Description de l'impact]
**Cause racine:** [Cause principale en une phrase]

## Timeline détaillée
| Heure | Événement | Action prise | Responsable |
|-------|-----------|--------------|-------------|
| 14:23 | Alerte monitoring | Investigation démarrée | @paul |
| 14:25 | Confirmation panne | Incident déclaré | @kevin |
| 14:30 | Cause identifiée | Fix en cours | @marie |
| 15:45 | Service restauré | Monitoring renforcé | @team |

## Cause racine
[Analyse détaillée de la cause. Pas de blâme, focus sur les systèmes et processus]

## Impact
- **Utilisateurs affectés:** [Nombre]
- **Durée d'indisponibilité:** [Durée]
- **Perte financière estimée:** [Montant]
- **Réputation:** [Impact]

## Ce qui a bien fonctionné
- [Action positive 1]
- [Action positive 2]
- [Action positive 3]

## Ce qui peut être amélioré
- [Point d'amélioration 1]
- [Point d'amélioration 2]
- [Point d'amélioration 3]

## Plan d'action
| Action | Responsable | Date cible | Status |
|--------|-------------|------------|--------|
| [Action 1] | @paul | 15/03 | 🔴 |
| [Action 2] | @marie | 20/03 | 🟡 |
| [Action 3] | @kevin | 30/03 | ⚪ |

## Apprentissages
[Ce que toute l'équipe doit retenir pour éviter des incidents similaires]

**Rédigé par:** [Nom]
**Reviewé par:** [Équipe]
**Date:** [Date]

Template de plan d’amélioration performance

# Plan d'amélioration - [Nom du développeur]

## Contexte
**Date de début:** [Date]
**Durée:** 3 mois
**Manager:** [Nom]
**Mentor assigné:** [Nom]

## Situation actuelle
### Points forts identifiés
- [Force 1]
- [Force 2]

### Points d'amélioration
- [Point 1]: [Description du problème]
- [Point 2]: [Description du problème]

## Objectifs SMART (3 mois)
- [ ] **Objectif 1:** [Spécifique, Mesurable, Atteignable, Réaliste, Temporalisé]
- [ ] **Objectif 2:** [Même format]
- [ ] **Objectif 3:** [Même format]

## Support fourni
- **Mentoring:** [Qui, quand, combien d'heures]
- **Formation:** [Quoi, quand, budget]
- **Ressources:** [Outils, documentation, accès]
- **Projets:** [Projets spécifiquement assignés pour progresser]

## Métriques de suivi
| Métrique | Baseline | Objectif | Fréquence mesure |
|----------|----------|----------|------------------|
| [Métrique 1] | [Valeur] | [Cible] | [Hebdo/Mensuel] |
| [Métrique 2] | [Valeur] | [Cible] | [Hebdo/Mensuel] |

## Points de contrôle
- **Semaine 3:** Premier checkpoint
- **Semaine 6:** Évaluation mi-parcours
- **Semaine 12:** Évaluation finale

## Conséquences
**En cas de progression satisfaisante:**
- [Récompenses, nouvelles responsabilités]

**En cas de progression insuffisante:**
- [Actions supplémentaires, changement de poste, ou séparation]

**Signatures:**
- Développeur: ________________ Date: _______
- Manager: ________________ Date: _______
- RH: ________________ Date: _______

Points clés à retenir

1. Anticipez les conflits. Les signaux faibles sont plus faciles à traiter que les crises ouvertes.

2. Restez factuel et bienveillant. Focus sur les comportements et l’impact, pas sur les personnes.

3. Organisez-vous avant la crise. Runbooks, rôles clairs, et process rodés font la différence.

4. Communiquez, communiquez, communiquez. En situation difficile, l’absence de communication créé plus de stress que la mauvaise nouvelle.

5. Prenez soin de vous. Vous ne pouvez pas aider votre équipe si vous êtes vous-même en difficulté.

6. Apprenez de chaque situation. Chaque conflit, chaque crise est une opportunité d’améliorer vos process et votre équipe.

Félicitations ! Vous avez terminé la partie Management et Leadership. Dans la partie suivante, on va plonger dans la stratégie technique : comment choisir les bonnes technologies, innover, et aligner technique et business.

---

“Les tempêtes ne durent pas éternellement. Mais un capitaine expérimenté sait naviguer dedans sans perdre son équipage.”