# 🔄 6TM — Transformation des développeurs exécutants 2026

> **Contexte** : L'IA augmente la productivité dev de 2x à 4x sur les tâches d'exécution standard. Le profil "développeur qui code ce qu'on lui dit de coder" perd de la valeur. 6TM doit transformer son capital humain avant que le marché ne l'impose brutalement.  
> **Porteurs** : Comex  
> **Horizon** : Année 2026  
> **Périmètre** : ~45 développeurs exécutants (junior/mid) sur ~55 devs total à affiner

---

## 1. Contexte — Pourquoi transformer maintenant

### Ce que l'IA compresse

| Tâche | Automatisabilité |
|---|---|
| Génération de CRUD / boilerplate | 🔴 Quasi-totale |
| Tickets simple | 🔴 Quasi-totale |
| Écriture de tests unitaires | 🔴 Élevée |
| Documentation technique | 🔴 Élevée |
| Correction de bugs décrits | 🟠 Moyenne |
| Refactoring guidé | 🟠 Moyenne |
| Conception d'architecture | 🟢 Faible |
| Cadrage fonctionnel | 🟢 Faible |
| Validation qualité IA | 🟢 Faible |

### Ce que ça implique pour 6TM

- Le même volume de livraison peut être atteint avec **moins de devs exécutants**
- Le goulet d'étranglement se déplace vers le **cadrage et la validation**
- Ne pas recruter en remplacement des départs naturels = économie structurelle
- Former les profils existants = préserver le capital humain et la connaissance métier accumulée, pouvoir accompagner la croissance

### Les deux leviers retenus

**Levier 1 — Attrition naturelle sans remplacement**  
Les départs ne sont pas remplacés sur les profils purement exécutants. Le volume se réduit progressivement sans plan social.

**Levier 2 — Plan de formation structuré interne**  
Le métier de dev se reconstruit autour de 4 dimensions. Le métier de développeur executant va disparaitre au profit d'un développeur Orchestrateur IA, chargé de piloter et valider les developpements générés par l'IA.
Cependant compte tenu de la rapidité de mise en place des features, une simple transformation de dev executant en orchestrateur IA junior ne sera pas suffisante à cause du goulet d'étranglement 

**Exemple concret :**
Un exécutant aujourd'hui à 90% dev passe à une composition cible 70% A / 30% B — il reste développeur, mais 70% de son temps est de l'orchestration IA et 30% de la prise en charge autonome de tickets fonctionnels.

---

## 2. Le modèle de composition — 4 dimensions, un mix par dev

Les 4 dimensions ne sont pas des cases exclusives — ce sont des axes d'allocation de temps. Chaque développeur a sa propre composition, définie selon son profil, son appétence et les besoins de l'équipe. La somme des dimensions doit atteindre 100%.

```
                    ┌─────────────────┐
                    │  Chef de projet │
                    └────────┬────────┘
                             │
        ┌────────────────────┼────────────────────┐────────────────────┐
        │                    │                    │                    │
   ┌────┴────┐          ┌────┴────┐          ┌────┴────┐          ┌────┴────┐
   │ Cible A1│          │ Cible A2│          │ Cible B │          │ Cible C │
   │Orchest. │          │ Orchest │          │ Relais  │          │ IA      │
   │ Junior  │          │ Senior  │          │ Fonct   │          │ DevOps  │
   └─────────┘          └─────────┘          └─────────┘          └─────────┘

```

> Chaque spécialisation est un **métier à part entière**. A1 et A2 partagent la même famille (orchestration) — A2 est une évolution naturelle de A1, pas une hiérarchie avec B et C.

---

### Dimension A — Orchestrateur IA Junior

Travaille sur des tâches bien délimitées avec l'IA, valide les outputs, progresse naturellement vers Lead Dev.

**Ce qu'il fait concrètement**
- Reçoit une tâche déjà décomposée et la traite avec l'IA en autonomie
- Valide le code généré avec une grille fournie par l'orchestrateur senior
- Supervise 1-2 devs juniors sur des tickets simples
- Construit progressivement ses propres prompts réutilisables
- Escalade au leads devssur les cas complexes ou ambigus

**Profils adaptés** : devs mid 2-3 ans d'expérience, déjà utilisateurs de Copilot/Claude Code, curieux et à l'aise avec l'expérimentation.  
**Levier principal** : binômage avec un Orchestrateur A2, formation PAI niveau 1.

---

### Cible A2 —  Lead Dev — Supervision technique & qualité IA  / Orchestrateur IA Senior

**Ce qu'il fait concrètement**
- Décompose les problèmes complexes en tâches IA-compatibles pour les A1
- Conçoit et maintient les Skills PAI internes 6TM (mono-repo)
- Définit les grilles de validation et les bonnes pratiques d'usage IA
- Supervise et débloque les orchestrateurs A1
- Interface avec le CP sur l'estimation et le risque technique
- Arbitre ce que l'IA peut traiter seule vs ce qui nécessite un humain

**Compétences concrètes à acquérir**

| Compétence | Comment |
|---|---|
| Découpage de problèmes complexes en tâches IA | Ateliers internes PAI, pratique sur vrais tickets |
| Rédaction de prompts avec contexte architectural | Formation Claude Code, revues de prompts en binôme |
| Relecture critique de code généré par IA | Grille de revue dédiée (dette, sécurité, cohérence) |
| Détection des hallucinations métier | Connaissance Gesteos/Seenaps + checklist de validation |
| Conception et maintenance des Skills PAI | Formation sur le mono-repo Skills 6TM |

**Profils adaptés** : devs seniors 5+ ans, expérience profonde sur Gesteos ou Seenaps.  
**Levier principal** : formation PAI niveau 2, contribution au mono-repo Skills 6TM.

---

### Cible B — Relais fonctionnel du chef de projet

**Ce qu'il fait concrètement**
- Lit et qualifie un ticket flou sans attendre une spec détaillée
- Estime et livre en autonomie sur les cas simples
- Utilise l'IA pour comprendre rapidement un contexte fonctionnel
- Distingue ce qu'il peut traiter seul de ce qui nécessite le CP
- Réduit les allers-retours CP sur le volume de tickets courants

**Profils adaptés** : devs avec bonne communication, expérience suffisante sur Gesteos ou Seenaps, à l'aise avec l'ambiguïté fonctionnelle.  
**Levier principal** : binômage CP/dev sur les petits tickets, grille de qualification autonome.

---

### Dimension C — Spécialiste IA & DevOps
 
Profil stratégique émergent. Développe les features IA dans les produits, maintient l'infrastructure PAI et maîtrise les pipelines CI/CD.
 
**Activités typiques**
 
*Features IA produits*
- Intégrer des fonctionnalités IA dans Gesteos et Seenaps (RAG, détection d'anomalies)
- Choisir et configurer les modèles adaptés à chaque cas d'usage
- Mesurer la performance des features IA en production
 
*Infrastructure PAI*
- Développer et maintenir les Skills et agents du mono-repo PAI 6TM
- Concevoir et exposer les MCP servers internes
- Gérer les intégrations entre outils IA
 
*DevOps & CI/CD*
- Maintenir et améliorer les pipelines GitLab CI
- Gérer les environnements Docker/GCP
- Automatiser les déploiements multi-tenants
 
**Profils adaptés** : devs full-stack 3-5 ans, curieux sur l'IA et à l'aise avec la ligne de commande.  
**Levier** : immersion projets PAI, formation CI/CD.
 

---

## 3. Exemples de compositions cibles
 
| Profil dev | Composition actuelle | Composition cible 2026 |
|---|---|---|
| Mid, curieux IA | 90% exécution, 10% autre | 70% A / 30% B |
| Senior, rigoureux | 60% exécution, 40% review | 50% Lead Dev / 30% A / 20% C |
| Full-stack, appétence infra | 80% exécution, 20% DevOps | 60% C / 40% A |
| Mid, bon communiquant | 80% exécution, 20% relation | 20% A / 80% B |
 
> La cartographie Q1 définira la composition réelle de chaque dev, en concertation individuelle.
 
---
 

## 4. OKR 2026
 
### Objective
 
> **Transformer le capital humain dev de 6TM** pour passer d'une équipe d'exécutants à une équipe de spécialistes IA-augmentés à composition mixte, sans plan social, par attrition naturelle et montée en compétence.
 
---
 
### KR1 — Cartographier et définir les compositions cibles
 
**100% des développeurs ont une composition cible définie** (répartition A / Lead Dev / B / C) d'ici fin Q1 2026.

- Etat : Non lance
- Avancement : 0%
- Actuel :
 
- Départ : 90%+ exécution pour la majorité
- Cible : composition individuelle documentée pour chaque dev
- Livrable : radar de compétences par dev + tableau de synthèse équipe
- Responsable : Philippe (DT)
 
---
 
### KR2 — Activer la dimension A et la filière Lead Dev
 
**Au moins 8 développeurs atteignent leur composition cible sur la dimension A** et **3 Lead Dev opérationnels** d'ici fin 2026.

- Etat : Non lance
- Avancement : 0%
- Actuel :
 
- Départ : usage IA informel, non structuré
- Cible A : 8 devs avec pratique IA mesurée en sprint
- Cible Lead Dev : 3 profils actifs sur revue de code IA + mono-repo Skills PAI
- Levier : programme interne PAI niveau 1 et niveau 2
- Indicateur : % de tâches de sprint assistées par IA déclaré en retro
 
---
 
### KR3 — Activer la dimension C
 
**Au moins 2 développeurs atteignent 40%+ sur la dimension C** d'ici fin 2026, avec au moins une feature IA livrée en production.

- Etat : Non lance
- Avancement : 0%
- Actuel :
 
- Départ : aucun profil dédié IA & DevOps
- Cible : 2 devs avec contribution mesurable PAI + CI/CD + feature IA produit
- Indicateur : nombre de Skills PAI créés + features IA en production
 
---
 
### KR4 — Réduire le ratio exécution pure
 
**La part moyenne de "dev exécution pure" dans les compositions passe de ~85% à ~55%** d'ici fin 2026.

- Etat : Non lance
- Avancement : 0%
- Actuel :
 
- Départ : ~85% du temps équipe en exécution pure
- Cible : ~55% — le reste réparti sur A, B, C, Lead Dev
- Levier : attrition naturelle non remplacée + requalification active
- Point de vigilance : maintenir la capacité de livraison grâce à la hausse de productivité IA
 
---
 
### KR5 — Mesurer la hausse de vélocité équipe
 
**La vélocité moyenne par développeur augmente de 30% minimum** entre Q1 et Q4 2026.

- Etat : Non lance
- Avancement : 0%
- Actuel :
 
- Départ : baseline à établir en Q1
- Cible : +30% en vélocité moyenne fin 2026
- Indicateur : story points livrés / dev / sprint
- Point de vigilance : suivre aussi le taux de bugs post-release
 
---
 
## 5. Plan de déploiement trimestriel
 
### Q1 2026 — Diagnostic & cartographie
- [ ] Entretien individuel avec chaque dev : composition actuelle + composition cible
- [ ] Construire le radar de compétences équipe (KR1)
- [ ] Établir la baseline de vélocité (KR5)
- [ ] Formaliser le programme de formation PAI
 
### Q2 2026 — Lancement
- [ ] Démarrer formations dimension A (KR2)
- [ ] Immerger les 2 candidats dimension C (KR3)
- [ ] Premier bilan attrition / non-remplacement (KR4)
- [ ] Premier point vélocité (KR5)
 
### Q3 2026 — Accélération
- [ ] Review mi-année OKR
- [ ] Promouvoir les premiers Lead Dev (KR2)
- [ ] Première feature IA en production (KR3)
- [ ] Activer les binômages CP/dev dimension B
 
### Q4 2026 — Bilan
- [ ] Mesure finale des 5 KRs
- [ ] Comparer radar cible vs radar réel pour chaque dev
- [ ] Décision plan 2027
- [ ] Partage résultats direction 6TM
 
---
 
## 6. Risques et points de vigilance
 
| Risque | Probabilité | Mitigation |
|---|---|---|
| Résistance culturelle à l'IA | 🟠 Moyenne | Composition individuelle — pas d'obligation brutale |
| Perte de capacité si attrition trop rapide | 🟠 Moyenne | Suivre la vélocité KR5 comme signal d'alerte |
| Qualité dégradée par vibe coding non supervisé | 🔴 Élevée | Lead Dev dédié à la revue — activer en priorité |
| Profil C difficile à constituer en interne | 🟠 Moyenne | Commencer par 1 candidat fort + montée progressive |
| Résistance du management à ne pas remplacer | 🟡 Faible | Argumenter avec les gains de vélocité mesurés |
 
---

*Document généré en avril 2026 — à réviser à chaque revue trimestrielle.*