MexarGestion d’une équipe de dev logiciel : ce que pilote le responsable métier
Vous n’avez pas besoin d’être développeur pour piloter une équipe de développement. Votre part tient en trois choses : une seule liste de demandes, classée ; des décisions de périmètre prises et écrites avant de développer ; une vérification régulière de ce qui est livré. L’organisation interne du travail des développeurs (outils, découpage technique, revues de code) leur appartient.
Par François Aubeut, fondateur de Mexar ·
Pour qui ? Les contenus sur la gestion d’équipe de développement s’adressent souvent aux managers techniques : structure d’équipe, recrutement, méthodes agiles. Cette page s’adresse au dirigeant ou au responsable métier d’une PME qui pilote un prestataire ou une petite équipe. La participation des utilisateurs à la construction (ateliers, prototypes, essais) est traitée dans développer un logiciel en équipe.
Responsabilités
Trois zones : la vôtre, celle de l’équipe, celle que vous partagez
La plupart des tensions viennent d’une zone mal tenue : un responsable qui choisit la technique, ou une équipe qui choisit seule les priorités faute de décision.
Vous pilotez
- L’objectif et le gain attendu
- L’ordre des demandes
- Ce qui entre ou non dans le périmètre
- La décision de mise en service
- La disponibilité des utilisateurs et des informations métier
Vous décidez ensemble
- Le contenu de chaque étape, en croisant valeur et effort
- Les compromis quand le délai ne tient pas
- Ce que « terminé » veut dire pour une demande
L’équipe pilote
- Les choix techniques et l’architecture
- Le découpage et l’organisation du travail
- L’estimation de l’effort
- La qualité du code, les tests, la sécurité
- L’alerte quand un délai ou un coût dérive
Dans le cadre Scrum, ce rôle de classement revient au Product Owner : le Scrum Guide 2020 en fait une seule personne, responsable de l’ordre du travail même si d’autres y contribuent (consulté le 24 octobre 2026). Vous n’êtes pas obligé d’adopter Scrum ; le principe d’une seule personne qui classe vaut quel que soit le cadre.
De la demande à la livraison
Le chemin d’une demande, et ce qui la fait avancer
Chaque demande franchit cinq étapes. Celle du milieu est la porte : rien ne se développe sans décision de périmètre écrite.
-
Recueillir
Toute demande arrive au même endroit, pas par un couloir ou un courriel direct à un développeur.
Passe quand la demande est écrite et son auteur connu.
-
Qualifier
Quel problème, pour qui, à quelle fréquence, comment fait-on aujourd’hui, que doit-il se passer ?
Passe quand un exemple réel est joint.
-
Décider du périmètre
L’équipe donne un ordre de grandeur d’effort ; vous tranchez : maintenant, plus tard ou non, avec la raison.
Passe quand la décision est inscrite au registre.
-
Développer
L’équipe s’organise comme elle l’entend. Vous restez joignable pour les questions métier.
Passe quand la demande peut être démontrée.
-
Vérifier et livrer
Démonstration sur des cas réels, puis mise en service décidée par vous.
Passe quand le critère « terminé » convenu est rempli.
Priorités
Classer les demandes sans tout mettre en urgent
Quatre critères aident à ordonner les demandes d’évolution. Pour qualifier l’urgence, documentez l’échéance extérieure (obligation réglementaire, engagement client, clôture comptable) ou le risque immédiat. Un incident bloquant, une faille de sécurité ou un risque de perte de données doit être traité selon sa gravité, même sans date imposée de l’extérieur.
- Gain attendu Temps récupéré, erreurs évitées, chiffre d’affaires protégé. C’est une estimation, à vérifier après livraison.
- Portée Combien de personnes, à quelle fréquence.
- Effort annoncé Ordre de grandeur donné par l’équipe, pas par vous.
- Échéance ou risque immédiat Une date imposée de l’extérieur, ou un incident dont la gravité justifie une prise en charge prioritaire.
| Demande | Gain attendu | Effort annoncé | Échéance extérieure | Décision |
|---|---|---|---|---|
| Relance automatique des devis non signés | Fort : temps commercial chaque semaine | Moyen | Aucune | Maintenant, n° 1 |
| Export comptable mensuel | Moyen | Faible | Clôture trimestrielle datée | Maintenant, n° 2 |
| Tableau de bord pour la direction | Faible à moyen | Moyen | Aucune | Plus tard |
| Changer la couleur des statuts | Faible | Faible | Aucune | Lot de petites corrections |
| Application mobile pour les commerciaux | Incertain | Fort | Aucune | Non pour l’instant : à requalifier |
Lecture : l’export comptable passe avant le tableau de bord grâce à son échéance datée et à son effort faible ; l’application mobile n’est pas refusée sur le fond, elle revient à l’étape « qualifier » faute d’exemple d’usage précis.
Coordination
Un rythme de coordination en quatre rendez-vous
La fréquence dépend de la taille du projet et de votre contrat ; elle est à convenir avec l’équipe. Ce qui compte, c’est que chaque rendez-vous produise une décision.
Point de priorités
Au début de chaque étape · vous et le référent technique
Il en sort la liste classée de l’étape, et ce qui reste en dehors.
Questions métier
Au fil de l’eau · vous ou un référent désigné
Il en sort des règles écrites, chacune avec un exemple réel. Une question sans réponse bloque un développeur.
Démonstration
À la fin de chaque étape · vous, des utilisateurs référents, l’équipe
Il en sort ce qui est accepté, ce qui est à reprendre, et les nouvelles demandes, inscrites dans la liste sans être promises.
Point de cap
Moins souvent · vous et le responsable de l’équipe ou du prestataire
Il en sort un état du budget, du délai et des risques, et les décisions de périmètre qui en découlent.
L’outil
Le registre des décisions de périmètre
Un simple tableau partagé suffit. Il évite de rediscuter une décision déjà prise et montre, à la fin, pourquoi le logiciel livré ressemble à ce qu’il est. Les deux premières lignes sont fictives ; la dernière est le modèle à recopier.
| Date | Demande | Décision | Raison | Effet sur le délai ou le budget | Décidé par |
|---|---|---|---|---|---|
| Exemple | Export comptable mensuel | Maintenant | Clôture trimestrielle datée, effort faible | Le tableau de bord passe à l’étape suivante | Responsable métier |
| Exemple | Ajouter un champ « transporteur » | Remplace une demande de même effort | Demandé en démonstration, utile tout de suite | Aucun : la demande remplacée revient dans la liste | Responsable métier, après avis de l’équipe |
| [À compléter : date] | [À compléter : demande] | [Maintenant / plus tard / non / remplace…] | [À compléter : raison] | [À compléter : effet] | [À compléter : nom] |
Quand une demande arrive en cours d’étape
Trois issues possibles, et une seule doit être choisie explicitement : elle remplace une demande d’effort comparable, elle attend l’étape suivante, ou elle fait l’objet d’un ajout chiffré au délai ou au budget. Avec un prestataire, la façon de traiter un ajout dépend du contrat : forfait, temps passé ou avenant.
Suivi
Ce que vous pouvez suivre sans lire le code
Quelques chiffres tirés du registre et de la liste suffisent à voir si le projet avance, et d’où vient un retard.
- Demandes en attente de votre décision. Si cette liste grossit, le retard se forme de votre côté, pas dans l’équipe.
- Prévu et livré à chaque étape, compté en demandes démontrées, pas en heures.
- Anomalies signalées, corrigées, encore ouvertes.
- Questions métier sans réponse au-delà du délai convenu.
- Budget : consommé au regard de l’avancement si vous payez au temps passé ; demandes hors périmètre si vous êtes au forfait.
Signaux d’alerte
Cinq situations à traiter tout de suite
- « Presque fini » plusieurs étapes de suite. Demandez à voir ce qui fonctionne, et redécoupez ce qui ne se démontre pas.
- Des demandes arrivent directement aux développeurs. Ramenez-les dans la liste unique, même les petites.
- Des décisions orales jamais écrites. Inscrivez-les au registre le jour même.
- Une seule personne connaît tout. Prévoyez documentation et transmission dès maintenant ; voir la passation d’un logiciel interne.
- Les utilisateurs découvrent l’outil à la mise en service. Faites-les participer avant ; voir développer un logiciel en équipe.
Avec Mexar
Le périmètre se décide avant de développer
Dans une mission ROI-first, la première amélioration est choisie selon les gains attendus, l’effort et le délai de retour. Le périmètre de la réalisation est cadré après l’audit et avant le développement, et le complément de prix est fixé au devis à ce moment-là. Le code, la documentation et la maîtrise des services tiers vous sont transmis. Les montants sont détaillés dans notre article sur le prix d’un développement logiciel.
Côté pilotage d’équipe, François Aubeut a été tech lead sur apps.education.fr, la plateforme d’applications libres des enseignants et des agents de l’Éducation nationale, avec l’encadrement de deux développeurs, puis lead developer de son adaptation interministérielle à la DINUM. Ce parcours, antérieur à la méthode, est présenté sur la page À propos.