Tableau de bord
Vue d'ensemble de vos activités
Tech Live Talk & Share
Sessions techniques bimensuelles — 1 jeudi sur 2
Développeurs
Suivi et historique de vos développeurs
Vie ma vie — Suivi IA
Suivi du potentiel IA des développeurs, session après session
Actions & Apps
Tâches, objectifs et applications
Nouveautés Omnes Education
Grosses nouveautés amenées chez Omnes Education
Rôle Tech Lead
Présentation et définition du rôle de Tech Lead
Présentations
Présentations PowerPoint au format HTML — dossier presentations/
Analyses & Indicateurs
Regroupement des analyses HTML et indicateurs clés
Mes formations
Les formations que j'aimerais suivre cette année
Pôle Devs
Stratégie de transformation du pôle développement — Omnes Education
Création du Pôle Développement centralisé
Plan stratégique et opérationnel pour la centralisation des développeurs des 4 domaines au sein de l'équipe CTO. Timeline : 6 mois.
Casser les silos — Chaque développeur est aujourd'hui spécialisé sur un seul projet. Cette dépendance crée un risque majeur (bus factor = 1) et empêche toute agilité dans la répartition des ressources.
Centraliser le pilotage — Les décisions d'allocation des ressources dev doivent être prises en fonction des priorités métier globales, pas par domaine isolé.
Monter en compétence — Construire une équipe polyvalente capable d'intervenir sur l'ensemble du portefeuille applicatif (Symfony, Node.js, React, Python, Power BI).
Standardiser les pratiques — Qualité de code, processus de review, documentation, CI/CD — un socle commun pour tous les projets.
Stack principale
PHP / Symfony Node.js React
Stack secondaire
Python Power BI
Point positif : La majorité des devs sont sur Symfony + React, ce qui rend la rotation réaliste sur 6 mois. Les profils Python / Power BI nécessiteront une stratégie spécifique.
Les développeurs appartiennent au Pôle CTO (leur "chapter") mais sont affectés temporairement à des projets (les "missions"). Le CTO décide des priorités d'affectation. Le Tech Lead DevOps (Kevin) pilote l'opérationnel technique et le suivi des développeurs.
Les responsables de domaine deviennent des demandeurs de ressources, pas des managers de développeurs.
Modèle organisationnel
Architecture du Pool de développeurs avec affectation par mission — inspiré du modèle Spotify adapté au contexte Omnes Education.
❌ Modèle actuel — Silos
Chaque domaine possède ses propres développeurs. Pas de vision transverse. Les devs sont enfermés dans un périmètre projet. Le bus factor est critique (= 1 par projet). Aucune flexibilité de réaffectation.
✅ Modèle cible — Pool centralisé
Tous les développeurs sont rattachés au Pôle CTO. Ils sont affectés par mission en fonction des priorités. La polyvalence est construite progressivement. Le CTO a une vision complète des ressources et peut arbitrer.
1. Ownership projet ≠ Ownership dev — Le responsable de domaine reste propriétaire de la vision métier de son projet. Mais il ne manage plus les développeurs. Il formule un besoin, le Pôle y répond.
2. Affectation temporaire, pas permanente — Un dev peut rester 3 mois sur un projet puis basculer. La durée dépend de la complexité et de la stratégie de rotation.
3. Pas de "dev attitré" — À terme, au moins 2 personnes doivent être capables d'intervenir sur chaque projet (bus factor ≥ 2).
4. Le Pôle est un collectif — Les devs ne sont pas des "mercenaires" isolés. Weekly commun, partage de pratiques, code reviews croisées, montée en compétence collective.
⚠️ Point de vigilance : Les profils Python / Power BI sont des cas particuliers. Leur rotation vers du Symfony/React (et inversement) est plus longue. Prévoir un plan de montée en compétence dédié ou les positionner comme "spécialistes transverses" sollicités en support.
Gouvernance
Circuit de décision, processus d'arbitrage et répartition des responsabilités entre le CTO, le Tech Lead et les domaines.
| Décision | Propose | Valide | Exécute |
|---|---|---|---|
| Priorité des projets | Responsables domaine | CTO | Kevin (affectation) |
| Affectation d'un dev à un projet | Kevin | CTO | Kevin |
| Rotation / réaffectation | Kevin | CTO | Kevin |
| Standards techniques (code quality, CI/CD) | Kevin | CTO | Kevin + Concepteur |
| Plan de montée en compétence | Kevin | CTO | Kevin |
| Gestion administrative (congés, RH) | Dev / Kevin | CTO | CTO |
Règle 1 — Pas de bypass. Un responsable de domaine ne peut pas demander directement à un dev de faire quelque chose. Tout passe par une demande formelle au Pôle.
Règle 2 — Transparence. Le board d'allocation (Azure DevOps) est visible de tous. Chaque domaine voit l'état de ses demandes et l'occupation des devs.
Règle 3 — Le CTO tranche. En cas de conflit de priorité entre domaines, c'est le CTO qui arbitre. Kevin peut recommander mais pas imposer sur les priorités métier.
Règle 4 — Protection des phases critiques. Un dev ne peut pas être réaffecté en plein sprint critique (go-live, migration, hotfix). Kevin veille à ce que les rotations se fassent à des moments opportuns.
Un comité hebdomadaire de 30 minutes entre le CTO et Kevin pour :
- Passer en revue les nouvelles demandes des domaines
- Valider / ajuster les affectations proposées par Kevin
- Identifier les risques de surcharge ou de sous-utilisation
- Planifier les rotations à venir (1 à 2 sprints d'avance)
- Arbitrer les conflits de priorité
Format recommandé : Kevin prépare un tableau de bord synthétique avant chaque comité. Le CTO valide en 30 min. Pas de réunion longue — on décide vite.
Plan de transition — 6 mois
Roadmap de transformation en 3 phases, de la préparation au déploiement complet.
Objectif : Poser les fondations du Pôle sans perturber les projets en cours.
- Semaine 1-2 : Valider le modèle avec le CTO. Formaliser les rôles (document officiel). Créer le board d'allocation sur Azure DevOps.
- Semaine 3-4 : Construire la matrice de compétences initiale (devs × projets × technos). Cartographier qui sait quoi.
- Semaine 5-6 : Communiquer aux responsables de domaine : le nouveau processus de demande, le calendrier, ce qui change pour eux.
- Semaine 7-8 : Communiquer aux développeurs. Entretien individuel avec chaque dev (comprendre ses aspirations, ses craintes, ses compétences réelles). Lancer les premiers 1-to-1.
Objectif : Tester le modèle sur un périmètre restreint. Valider que ça marche avant de généraliser.
- Sélection : Choisir les 2 domaines les plus matures / les plus ouverts au changement. Éviter de commencer par le domaine le plus résistant.
- Premier binômage : Affecter un dev d'un domaine en observation/binôme sur un projet de l'autre domaine. Pas de prise de responsabilité immédiate — montée progressive.
- Activer les rituels : Weekly Pôle Dev, weekly pilotage CTO, 1-to-1 bimensuels. Tester et ajuster le rythme.
- Processus de demande : Les 2 domaines pilotes commencent à utiliser le board d'allocation formel.
- Retour d'expérience : À M+4, RETEX formalisé avec le CTO. Qu'est-ce qui fonctionne ? Qu'est-ce qui frotte ?
Objectif : Étendre le modèle à l'ensemble des 4 domaines.
- Intégration des 2 domaines restants selon le même schéma (communication, entretiens individuels, board d'allocation).
- Premières rotations réelles : Les devs qui ont été en binôme pendant la phase pilote commencent à prendre des missions autonomes sur les projets découverts.
- Stabilisation : Tous les rituels sont en place, la matrice de compétences est mise à jour, le comité d'allocation est rodé.
- Bilan M+6 : Mesure des KPIs. Rapport au CTO. Ajustements pour la suite.
⚠️ Facteur clé de succès : La communication. Ce changement peut être perçu comme une perte de pouvoir par les responsables de domaine et comme une source d'instabilité par les développeurs. Il faut anticiper les résistances et y répondre avec transparence.
Rôles & responsabilités
Qui fait quoi dans le nouveau modèle. Clarté des rôles = condition n°1 de réussite.
CTO — Responsable du Pôle
Responsable hiérarchique de tous les développeurs. Arbitre les priorités métier et l'allocation des ressources. Valide les propositions de Kevin. Gère l'administratif (congés, RH, salaires). Porte la vision stratégique du Pôle auprès de la direction.
Tech Lead DevOps (Kevin) — Pilote opérationnel
Pilotage technique quotidien des développeurs. Propose les affectations et rotations. Anime les rituels du Pôle (weekly, 1-to-1). Suit la montée en compétence et la matrice. Garant de la qualité du code, des standards et des bonnes pratiques. Point de contact technique pour les responsables de domaine. Remonte les alertes et risques au CTO.
Concepteur Technique
Architecture et conception technique des projets. Support transverse aux développeurs sur les choix d'architecture. Co-construction des standards techniques avec Kevin. Intervient en amont des nouvelles features ou des refontes.
Responsable de domaine — Demandeur
Formule les besoins de développement via le processus formel. Fournit le contexte métier et les spécifications. Priorise ses propres demandes. N'a plus de lien hiérarchique avec les devs. Reste propriétaire de la vision métier de ses projets.
Développeur — Membre du Pôle
Rattaché hiérarchiquement au CTO. Affecté à des missions par Kevin. Participe aux rituels du Pôle. Contribue à la documentation et au knowledge transfer. Monte en compétence sur plusieurs projets/stacks progressivement.
🚨 Point critique : Le rôle de Kevin doit être formalisé officiellement. Un titre interne (ex: "Responsable opérationnel du Pôle Dev" ou "Lead technique du Pool") est nécessaire. Sans légitimité formelle, Kevin portera la charge sans l'autorité — recette pour le burnout.
Rituels de suivi
Le bon dosage : assez de suivi pour piloter, pas assez pour étouffer. Voici le cadre recommandé.
| Rituel | Fréquence | Durée | Participants | Objectif |
|---|---|---|---|---|
| Daily projet | Quotidien | 15 min | Devs affectés au projet | Sync opérationnel du projet. Kevin n'y participe pas systématiquement. |
| Weekly Pôle Dev | Hebdo (mardi recommandé) | 30 min | Kevin + tous les devs | Cohésion d'équipe, annonces, partage de bonnes pratiques, REX. |
| Weekly Pilotage | Hebdo (jeudi recommandé) | 30 min | Kevin + CTO | Alertes, arbitrages, validation des affectations, planification rotations. |
| 1-to-1 Dev | Bimensuel | 20 min | Kevin + 1 dev | Suivi individuel, montée en compétence, moral, aspirations. |
| Comité d'allocation | Hebdo (intégré au weekly pilotage) | inclus | Kevin + CTO | Traitement des demandes, affectations, réaffectations. |
| Rétrospective Pôle | Mensuelle | 45 min | Kevin + tous les devs | Amélioration continue du fonctionnement du Pôle. |
💡 Pourquoi pas de daily global ? Avec 5-10 devs sur des projets différents, un daily commun n'aurait aucune valeur : chacun parle de sujets qui ne concernent pas les autres. Les dailies restent au niveau projet. Le weekly Pôle suffit pour la cohésion et le partage.
| Rituel | Scénario 5 devs | Scénario 10 devs |
|---|---|---|
| Weekly Pôle Dev | 30 min / semaine | 30 min / semaine |
| Weekly Pilotage CTO | 30 min / semaine | 30 min / semaine |
| 1-to-1 bimensuels | ~50 min / semaine | ~1h40 / semaine |
| Préparation + suivi boards | ~1h / semaine | ~2h / semaine |
| Total suivi | ~3h / semaine | ~5h / semaine |
C'est gérable, même à 10 devs. La clé : être structuré et ne pas laisser les rituels déborder. Un 1-to-1 de 20 min qui dure 45 min sur chaque dev, ça tue le modèle.
Processus d'allocation
Comment les domaines demandent des développeurs et comment le Pôle répond.
Chaque demande doit contenir les champs suivants. À implémenter comme Work Item Type dans Azure DevOps.
Un board Kanban dédié avec les colonnes suivantes :
💡 Astuce : Ajouter un tag par domaine (Domaine 1, 2, 3, 4) sur chaque work item pour pouvoir filtrer rapidement et produire des stats d'allocation par domaine.
Matrice de compétences
L'outil central pour piloter la polyvalence et identifier les zones de risque.
| Niveau | Label | Définition |
|---|---|---|
| 0 | Inconnu | N'a jamais travaillé sur ce projet / cette techno |
| 1 | Notions | A fait du binômage ou une exploration. Peut intervenir en support avec accompagnement. |
| 2 | Autonome | Peut prendre en charge des tâches standard sans assistance. Connaît le codebase. |
| 3 | Référent | Expert du projet. Maîtrise l'historique, les edge cases, les décisions d'architecture. |
| Développeur | Projet Alpha Symfony |
Projet Beta React + Node |
Projet Gamma Symfony |
Projet Delta Python + PBI |
Bus Factor |
|---|---|---|---|---|---|
| Dev A | 3 | 0 | 1 | 0 | Risque |
| Dev B | 0 | 3 | 0 | 0 | Risque |
| Dev C | 0 | 0 | 3 | 0 | Risque |
| Dev D | 0 | 0 | 0 | 3 | Risque |
| Dev E | 2 | 1 | 0 | 0 | Moyen |
| Personnes à niveau ≥ 2 par projet : | |||||
| OBJECTIF | ≥ 2 | ≥ 2 | ≥ 2 | ≥ 2 | Sécurisé |
🚨 Situation initiale probable : Chaque projet n'a qu'un seul référent (niveau 3). C'est exactement le problème à résoudre. L'objectif à M+6 est d'avoir au minimum 2 personnes à niveau ≥ 2 sur chaque projet critique.
La matrice est mise à jour mensuellement par Kevin, idéalement lors des 1-to-1. C'est un outil vivant, pas un document figé. Elle sert à piloter les affectations et à mesurer la progression de la polyvalence.
Rotation & montée en compétence
Comment rendre les devs polyvalents sans mettre les projets en danger.
Règle 1 — Jamais seul sur un nouveau projet. Un dev qui découvre un projet est toujours en binôme avec le référent. Pas d'autonomie avant d'avoir atteint le niveau 1 minimum.
Règle 2 — Jamais en phase critique. On ne retire pas un dev d'un projet pendant un go-live, une migration, ou un sprint de correction urgente. Les rotations se planifient 1-2 sprints à l'avance.
Règle 3 — Le référent reste joignable. Quand un dev prend le relais sur un projet, l'ancien référent reste disponible pour des questions pendant au moins 2 semaines de transition.
Règle 4 — La rotation est progressive. On ne fait pas tourner tout le monde en même temps. Maximum 1-2 rotations simultanées pour garder la stabilité.
Règle 5 — La doc précède la rotation. Avant de faire tourner, s'assurer que le projet a un minimum de documentation (README, architecture, setup local, process de déploiement).
Le dev observe le référent travailler. Il lit la doc, explore le codebase, comprend l'architecture. Il ne code pas encore.
Le dev prend en charge des tâches simples (bugfix, petites features) avec le référent en pair programming ou en review immédiate. Il passe au niveau 1.
Le dev travaille de manière autonome avec le référent disponible pour les questions. Code reviews systématiques par le référent. Il progresse vers le niveau 2.
Le dev est autonome sur le projet. Il peut prendre en charge des features complètes. Il est au niveau 2. Avec le temps et l'expérience, il pourra atteindre le niveau 3.
Devs Symfony ↔ Symfony
Rotation fluide. Même stack, seul le contexte métier change. Prévoir 2-3 semaines de montée en compétence sur le codebase.
Devs Symfony ↔ React/Node
Rotation possible mais plus longue. Si le dev a des bases JS, prévoir 4-6 semaines. Sinon, commencer par une formation ciblée avant la rotation.
Devs Python / Power BI
Profils spécialisés. Rotation vers Symfony/React = longue et coûteuse. Mieux vaut les positionner en "spécialistes transverses" qui interviennent en support data sur plusieurs projets.
Levier : Code Reviews croisées
Même sans rotation formelle, demander à un dev de reviewer du code d'un autre projet est un excellent moyen de monter en compétence à faible coût.
✅ Quick win : Dès la phase pilote, instaurer les code reviews croisées entre projets Symfony. C'est la manière la moins perturbante de commencer la polyvalence : le dev ne quitte pas son projet mais découvre un autre codebase par la review.
KPIs & mesure
Ce qui ne se mesure pas ne s'améliore pas. Voici les indicateurs à suivre.
| KPI | Mesure | Fréquence | Cible M+6 | Source |
|---|---|---|---|---|
| Bus factor par projet | Nb de personnes niveau ≥ 2 | Mensuel | ≥ 2 sur chaque projet | Matrice de compétences |
| Taux de polyvalence | % devs actifs sur ≥ 2 projets | Mensuel | ≥ 50% | Matrice de compétences |
| Délai d'allocation | Jours entre demande et affectation | Par demande | ≤ 5 jours | Board Azure DevOps |
| Satisfaction des domaines | Score qualitatif (1-5) | Trimestriel | ≥ 3.5 / 5 | Enquête rapide |
| Satisfaction des devs | Score qualitatif (1-5) | Trimestriel | ≥ 4 / 5 | 1-to-1 / enquête |
| Taux d'occupation | % du temps affecté vs dispo | Hebdo | 75-90% | Board Azure DevOps |
| Nb de code reviews croisées | Reviews inter-projets / mois | Mensuel | ≥ 2 par dev | Azure DevOps / Git |
| Couverture documentaire | % projets avec doc à jour | Mensuel | 100% | Audit manuel |
💡 Conseil : Ne pas surcharger de KPIs au départ. Commencer par les 3 essentiels : bus factor, délai d'allocation, satisfaction devs. Ajouter les autres progressivement.
Risques & mitigations
Les choses qui peuvent mal tourner — et comment les anticiper.
| Risque | Impact | Probabilité | Mitigation |
|---|---|---|---|
| Résistance des responsables de domaine Perte de pouvoir perçue sur "leurs" devs |
Élevé | Haute | Communication précoce et transparente. Montrer les bénéfices : ils n'ont plus à gérer les devs, ils peuvent se concentrer sur le métier. Impliquer les domaines dans la définition du process. |
| Déstabilisation des développeurs Perte de repères, sentiment de ne plus avoir de "maison" |
Élevé | Moyenne | Entretiens individuels dès la phase 1. Le Pôle doit devenir leur nouvelle "maison" — weekly, rétros, 1-to-1. Leur montrer que c'est une opportunité (polyvalence, visibilité CTO). |
| Perte de productivité pendant la transition Les rotations ralentissent temporairement les projets |
Moyen | Haute | C'est attendu et acceptable. Binômage pour limiter l'impact. Ne pas faire tourner pendant les phases critiques. Communiquer aux parties prenantes que c'est un investissement. |
| Surcharge de Kevin Gérer 10 devs + DevOps + projets existants |
Élevé | Moyenne | Formaliser la charge de suivi (cf. page rituels). Mettre des limites claires. Déléguer certaines tâches au Concepteur Technique. Le CTO doit alléger d'autres responsabilités si nécessaire. |
| Bypass du processus Les domaines continuent à demander directement aux devs |
Moyen | Moyenne | Règle claire dès le jour 1 : aucune demande informelle. Le CTO doit porter ce message. Les devs doivent aussi apprendre à rediriger vers le board. |
| Rotation trop rapide Les devs survolent les projets sans approfondir |
Moyen | Faible | Durée minimum d'affectation : 2-3 sprints. Pas de rotation avant d'avoir atteint le niveau 1. La matrice de compétences contrôle la progression. |
| Rôle de Kevin non formalisé Responsabilité sans autorité = frustration |
Élevé | Moyenne | Obtenir un titre et un mandat formel du CTO avant de lancer la phase 1. C'est un prérequis, pas un nice-to-have. |
- Rôle de Kevin formalisé avec titre et mandat officiel
- Modèle organisationnel validé par le CTO
- Board d'allocation créé sur Azure DevOps
- Template de demande de ressource créé
- Matrice de compétences initiale construite
- Communication aux responsables de domaine effectuée
- Communication aux développeurs effectuée
- Entretiens individuels avec chaque dev réalisés
- Rituels planifiés dans les agendas
- 2 domaines pilotes sélectionnés
🎯 Rappel : L'objectif n'est pas la perfection au jour 1. C'est de poser un cadre solide, de le tester, et de l'ajuster. La phase pilote existe précisément pour ça. L'important est de commencer avec les fondations en place.
Maintenance
Gestion des données de l'application
Utilisateurs
Gestion des comptes et des droits d'accès
Entretien
Évaluation technique des développeurs — cadrage, banque de questions, fiches candidats