Développer un logiciel en équipe : avec le métier, pas seulement entre développeurs

Pour une application métier, développer en équipe, c’est faire travailler sur le même objet trois groupes qui savent des choses différentes : les utilisateurs, qui connaissent le travail réel, le responsable métier, qui tranche, et les développeurs, qui construisent. Leur point de rencontre n’est pas un cahier des charges épais, mais une boucle courte : observer le travail, montrer une ébauche, faire essayer, ajuster.

Par François Aubeut, fondateur de Mexar · 29 octobre 2026

Illustration générée : trois groupes distincts façonnent ensemble un même objet. Ce n’est pas une capture d’application.

Les rôles

Trois groupes, trois savoirs qui ne se remplacent pas

Chacun détient une partie de la réponse. Le travail en équipe consiste à les réunir au bon moment, sans demander à l’un de faire le métier de l’autre.

Les utilisateurs

Ils savent comment le travail se fait vraiment : les étapes, les exceptions, les contournements, ce qui fait perdre du temps.

Leur part. Montrer leur travail, essayer les ébauches, dire ce qui bloque.

Pas leur rôle. Rédiger des spécifications ou choisir la technique.

Le responsable métier

Il sait pourquoi on fait le projet : l’objectif, le gain attendu, les contraintes de l’organisation.

Sa part. Arbitrer entre les demandes, fixer ce qui entre dans la version en cours, décider quand l’application est prête pour l’usage.

Pas son rôle. Décider seul, à la place des utilisateurs, de la façon dont ils travaillent au quotidien.

Les développeurs

Ils savent ce qui est faisable, à quel coût, et comment construire pour que l’application tienne dans la durée.

Leur part. Proposer des solutions, rendre visibles les compromis, construire et corriger.

Pas leur rôle. Deviner le métier ou trancher seuls une règle de gestion.

La méthode

Quatre façons de travailler ensemble, en boucle

Atelier, prototype, démonstration, essai en situation : chaque format répond à une question différente. Ils se répètent tant que l’application n’est pas prête pour l’usage, et un essai en situation fournit souvent la matière du prochain atelier.

Atelier sur le travail réelComprendre le processus tel qu’il se pratique.
PrototypeRendre une idée discutable avant de la construire.
DémonstrationMontrer ce qui fonctionne et décider de la suite.
Essai en situationVérifier que l’application tient face au vrai travail.

Ce que l’essai révèle revient à l’atelier suivant.

Schéma de principe de la boucle de construction avec le métier.

L’atelier sur le travail réel

Objectif: Comprendre le processus tel qu’il se pratique, pas tel qu’il est décrit dans une procédure.
Autour de la table: Quelques personnes qui font le travail, le responsable métier, au moins un développeur.
À apporter: De vrais exemples : un dossier, un fichier, un bon de commande, le cas qui pose toujours problème. Anonymisés si nécessaire.
Ce qui en sort: Le parcours décrit étape par étape, avec ses exceptions et ses points de friction, et la liste des questions encore ouvertes.
Piège: Demander « de quoi avez-vous besoin ? » au lieu de « montrez-moi la dernière fois que vous l’avez fait ». La première question produit des souhaits, la seconde des faits.

Le prototype

Objectif: Rendre une idée discutable avant d’investir dans sa construction.
Sa forme: Un croquis, une maquette cliquable ou un premier écran qui fonctionne avec des données fictives. Le niveau de finition suit la question posée.
Autour de la table: Les utilisateurs et le développeur qui l’a préparé.
Ce qui en sort: Des corrections sur le parcours, les mots employés, l’ordre des informations, et la liste de ce qui n’est finalement pas nécessaire.
Piège: Un prototype trop fini : on commente les couleurs au lieu du parcours, ou l’on croit l’application presque terminée. Dites à chaque présentation ce qui est factice.

La démonstration

Objectif: Montrer ce qui fonctionne réellement depuis la dernière fois, puis décider de la suite.
Autour de la table: Le responsable métier, des utilisateurs référents, les développeurs.
Ce qui en sort: Ce qui est accepté, ce qui est à reprendre, les priorités de l’étape suivante. Les nouvelles idées sont notées, pas promises.
Piège: Seuls les développeurs manipulent, ou l’on montre des captures au lieu de l’application qui tourne. Faites manipuler un utilisateur.

L’essai en situation

Objectif: Vérifier que l’application tient face au vrai travail : vrais volumes, vraies exceptions, vrai poste de travail.
Autour de la table: Les utilisateurs, à leur poste, avec un développeur présent ou joignable.
Ce qui en sort: Les anomalies, les manques, les contournements observés, puis la décision de mise en usage, prise par le responsable métier.
Piège: N’essayer que les cas simples. « Ça marche en démonstration » ne dit pas que ça marche un jour chargé, avec le dossier incomplet de la fin de semaine.

Les décisions

Qui tranche quoi, et sur quelle preuve

Quand personne n’est désigné pour trancher, la décision revient par défaut à la personne qui écrit le code. Ce n’est pas un reproche fait aux développeurs : c’est mécanique. Ce tableau rend les décisions explicites et dit sur quoi chacune s’appuie.

Les décisions de construction et leur preuve
Décision	Qui propose	Qui tranche	Sur quelle preuve
Le problème à résoudre en premier	Utilisateurs et responsable métier	Responsable métier	Le travail observé en atelier et le gain attendu
Le parcours à l’écran : étapes, mots, ordre	Développeurs, à partir de l’atelier	Utilisateurs	Un essai du prototype sur un cas réel
Une règle de gestion : calcul, contrôle, exception	Utilisateurs	Responsable métier	Un exemple réel écrit, avec le résultat attendu
La solution technique	Développeurs	Développeurs, en exposant coût et limites	Faisabilité, maintenance et coût annoncés au responsable
Ce qui entre dans la version en cours	Tous	Responsable métier	Le gain, l’effort annoncé par les développeurs, le délai
La mise en usage	Développeurs et utilisateurs	Responsable métier	Des essais en situation concluants sur les cas convenus

Exemple fictif

Une application de demandes d’intervention, rencontre après rencontre

Une PME de maintenance industrielle imaginaire suit ses demandes d’intervention dans un tableur. Voici ce que chaque rencontre change au produit. L’entreprise, les personnes et les constats sont inventés pour illustrer la méthode.

Atelier

Deux techniciens et l’assistante de planification montrent comment une demande arrive (appel, courriel, papier) et finit dans le tableur. Constat : la vraie difficulté n’est pas la saisie, mais savoir quelle pièce manque pour intervenir.
Prototype

Trois écrans maquettés. Les techniciens rayent la moitié des champs prévus et demandent à voir les pièces manquantes en premier.
Démonstration

La liste des demandes fonctionne avec des données d’essai. La responsable reporte l’export comptable à une étape ultérieure pour livrer d’abord le suivi des pièces.
Essai en situation

Une équipe l’utilise sur ses demandes réelles. Trois exceptions apparaissent, dont des demandes sans numéro de machine ; deux sont corrigées, la troisième est traitée par une règle manuelle provisoire. La mise en usage est décidée.

Chaque rencontre a changé le produit. Une rencontre qui ne change rien mérite une question : arrivait-elle trop tard, ou montrait-on quelque chose de trop fini pour être discuté ?

Avant de commencer

Ce que le métier doit pouvoir fournir

La construction conjointe demande du temps aux équipes métier. Ce temps fait partie de l’investissement : mieux vaut le prévoir dès le départ que le prendre sur l’urgence du quotidien.

Une personne qui tranche, légitime pour arbitrer et présente aux démonstrations.
Quelques utilisateurs référents qui font réellement le travail, pas seulement leur responsable.
Du temps réservé dans leur agenda pour les ateliers et les essais.
Des exemples réels : dossiers, fichiers, cas difficiles, anonymisés si nécessaire.
Un accès aux données, ou à des données d’essai représentatives.
Un critère de réussite simple : ce que l’on veut voir changer dans le travail (temps, erreurs, ressaisies).

Signaux

Quand la collaboration dérape, et quoi faire

Les retours n’arrivent qu’à la livraison.: Montrez plus tôt, sur un prototype ou une version partielle.
Le responsable valide seul, les utilisateurs découvrent l’outil au démarrage.: Faites essayer par ceux qui feront le travail avant la décision de mise en usage.
Chaque démonstration ajoute des demandes et rien ne sort.: Gardez une seule liste et une seule personne qui classe. C’est un sujet de pilotage de l’équipe.
Les développeurs posent des questions métier qui restent sans réponse.: Désignez un référent joignable et écrivez chaque règle avec un exemple réel.
Le prototype est pris pour le produit fini.: Signalez ce qui est factice à chaque présentation.

Sur le terrain

Construire avec celles et ceux qui connaissent le métier

Chez Carrier, François Aubeut a créé avec l’équipe une application métier pour les laboratoires et la R&D : choix techniques, interface, modèle de données et accompagnement des techniciens. Avec Partitio, il a travaillé avec l’équipe métier à structurer un savoir-faire d’évaluation avant de le transformer en application. Le parcours de François Aubeut, fondateur de Mexar

Ces projets font partie du parcours de François et ne sont pas présentés comme des missions ROI-first ; la réalisation laboratoire en donne le détail public. Dans la méthode ROI-first, « construire avec les utilisateurs » est une étape à part entière : nous montrons tôt, faisons essayer en situation et ajustons, avant de mesurer les gains.

Décrire votre processus