Par Thomas Cohen, fondateur de Maestro
Créer une application interne pour une petite équipe
Répartir les décisions, éviter les réservations en conflit et organiser un pilote : un guide concret pour construire un outil commun avec les personnes qui l’utiliseront.
Votre équipe veut une application interne. Chacun connaît une partie du travail : planning, suivi des demandes ou informations à transmettre. Avant de construire, il faut transformer ces attentes en décisions communes : ce qui entre dans la première version, qui peut faire quoi et comment vérifier le résultat quand plusieurs personnes travaillent ensemble.
Suivons un collectif fictif qui prête des outils et organise des ateliers de réparation. Maya prépare les permanences, Étienne suit le matériel et Alice accueille les participants. Ils travaillent à des horaires différents et veulent mieux gérer les réservations. Les noms, l’association et les situations sont inventés pour expliquer une méthode applicable à une petite équipe, sans constituer un témoignage client.
1. Partir d’un passage de relais qui pose problème
Demandez à chaque personne de raconter une situation récente, du début à la fin. Évitez « il nous faut un tableau de bord ». Cherchez plutôt qui attend quelle information, à quel moment et avec quelle conséquence. Le besoin d’une équipe apparaît souvent entre deux tâches, lorsque le travail de l’un doit devenir utilisable par l’autre.
Dans notre collectif, Alice reçoit une demande de perceuse par téléphone. Elle la note dans un carnet. Étienne voit une perceuse sur l’étagère et la prête à quelqu’un d’autre. Le problème n’est pas seulement de saisir plus vite : les deux personnes ne partagent pas une réservation confirmée avant de promettre le même outil.
Reconstituez ce parcours avec des exemples préparés pour la discussion. Où arrive la demande ? Qui confirme ? Quand le matériel devient-il indisponible ? Comment un retour en retard est-il signalé ? Notez les réponses différentes. Elles révèlent des règles à décider, pas une faute à attribuer à un collègue.
Écrivez une phrase qui décrit le résultat attendu : « Avant de confirmer un prêt, chacun doit voir si cet outil est disponible pour la période demandée. » Cette phrase donne un critère au premier essai. Elle évite de construire une application très remplie qui laisserait intact le désaccord de départ.
2. Nommer qui tranche, qui contribue et qui vérifie
Une petite équipe peut décider rapidement, à condition que la responsabilité soit claire. Choisissez une personne qui rassemble les demandes et arbitre le périmètre. Elle ne devient pas propriétaire de toutes les idées. Elle évite simplement que deux consignes incompatibles partent en parallèle vers la personne ou les agents qui construisent.
Maya tient ce rôle dans notre exemple. Étienne explique les règles de prêt et vérifie le suivi du matériel. Alice teste l’accueil et les réservations. Une personne compétente prend en charge les choix techniques et l’entretien. Plusieurs rôles peuvent être tenus par la même personne, mais aucun ne doit rester implicite.
- La personne qui arbitre accepte une fonction, la reporte ou demande des précisions.
- Les utilisateurs décrivent les situations et les exceptions qu’ils rencontrent.
- Les vérificateurs essaient les parcours et consignent les résultats observés.
- La personne chargée de l’entretien prépare les accès, les corrections et la continuité.
Prévoyez également le remplacement du responsable. Si Maya est absente, qui peut autoriser une correction urgente et quel budget peut être engagé ? Une courte règle écrite évite à l’équipe d’attendre un message informel pour chaque décision. L’outil pourra vous aider à conserver les choix ; il ne peut pas choisir légitimement les priorités à votre place.
3. Construire une première version qui traverse les rôles
La tentation consiste à demander un écran pour chaque personne : planning de Maya, inventaire d’Étienne, liste d’Alice. Commencez plutôt par un parcours qui relie leurs actions. Une première version utile permettrait de demander un outil, de confirmer sa disponibilité, d’enregistrer sa sortie et de noter son retour.
Ce parcours doit être complet sur un périmètre limité. Le collectif choisit quelques outils d’essai et laisse de côté les paiements, les adhésions et les messages automatiques. Il ne remplace pas encore toute son organisation. Les exclusions sont écrites, afin qu’un écran ajouté en cours de route ne change pas discrètement l’objectif.
Préparez des situations qui forcent une décision : un prêt normal, un retour en retard, un outil indisponible et une annulation. Pour chacune, indiquez le point de départ, l’action et le résultat attendu. Une maquette peut montrer les écrans ; ces situations montrent ce que l’équipe attend du fonctionnement.
Le cahier des charges non technique aide à rassembler ce périmètre. Faites-le relire à quelqu’un qui assure une permanence sans participer au projet. S’il comprend ce qu’il pourra faire et ce qui reste exclu, vous disposez d’une base plus solide qu’une liste de fonctionnalités aux intitulés séduisants.
4. Définir les mêmes mots et les mêmes informations
Une application commune ne rapproche pas automatiquement des habitudes différentes. « Réservé » signifie-t-il demandé, accepté ou déjà remis ? « Disponible » inclut-il un outil en réparation ? Faites définir les mots avant de choisir les couleurs. Une interface claire peut encore conduire à de mauvaises décisions si chacun comprend ses états autrement.
Le collectif distingue « demande reçue », « réservation confirmée », « outil sorti » et « retour enregistré ». L’outil en réparation reste indisponible, même s’il est physiquement sur l’étagère. Étienne confirme les transitions autorisées : une demande peut être annulée ; un outil sorti doit faire l’objet d’un retour ou d’un signalement adapté.
Attribuez un repère stable à chaque outil. Deux perceuses identiques doivent pouvoir être distinguées si elles ont des disponibilités différentes. Décidez aussi quels renseignements sont nécessaires sur l’emprunteur. Une note libre ne doit pas devenir l’endroit où l’équipe accumule des détails personnels sans utilité pour le prêt.
Préparez une petite fiche de vocabulaire avec un exemple par état. Ajoutez qui peut corriger une erreur et comment retrouver la correction. Ce document accompagne l’application pendant les essais. Si un nouveau terme apparaît dans l’interface, demandez pourquoi il est nécessaire avant de laisser se former deux façons de décrire la même situation.
5. Décider les droits à partir des actions
Écrivez les actions que chaque rôle doit pouvoir réaliser : consulter les disponibilités, confirmer une réservation, corriger un retour, sortir une liste ou gérer les comptes. « Membre de l’équipe » reste trop large. Alice et Étienne peuvent avoir besoin d’informations différentes, même s’ils travaillent pour la même association.
La CNIL recommande de limiter les droits au besoin de la mission et de les réexaminer. Traduisez cette règle en situations que vos utilisateurs pourront vérifier.
Dans l’essai fictif, Alice peut confirmer un prêt mais ne modifie pas l’état de réparation d’un outil. Étienne peut rendre l’outil disponible après contrôle. Maya peut organiser un remplacement temporaire. Faites essayer les actions autorisées et refusées avec des comptes distincts, y compris la consultation d’un lien reçu d’un autre utilisateur.
La fin d’une permanence ou le départ d’un bénévole doit aussi avoir un traitement prévu. Qui signale le changement et qui le réalise dans l’application ? Conservez des consignes adaptées à l’équipe. Une configuration correcte lors du lancement ne garantit pas qu’elle le restera si les responsabilités changent sans que personne ne s’en occupe.
6. Prévoir deux personnes sur le même dossier
Alice et Étienne ouvrent la même disponibilité à quelques secondes d’intervalle. Chacun voit encore une perceuse libre et confirme une réservation pour le samedi. Si l’application accepte les deux demandes sans contrôle, les écrans peuvent paraître corrects alors que le collectif vient de promettre un outil deux fois.
Décrivez la règle avant de demander sa mise en œuvre : une seule réservation confirmée peut occuper cet outil sur une période donnée. La seconde personne doit recevoir une explication et une possibilité d’ajuster sa demande. Ne lui laissez pas croire que son opération a réussi si elle a été refusée ou reste incertaine.
La documentation de PostgreSQL sur les opérations simultanées décrit des conflits et des reprises nécessaires. Leur traitement dépend de l’application ; l’équipe technique doit le vérifier.
Préparez ensuite un essai à deux comptes. Ouvrez le même créneau, confirmez presque simultanément, puis contrôlez les deux résultats et la liste finale. Recommencez avec une annulation et un retard de retour. Votre rôle consiste à valider le comportement métier ; la personne technique doit vérifier le mécanisme qui le garantit.
7. Organiser les demandes sans changer de direction chaque jour
Gardez une seule liste de demandes, accessible aux personnes concernées. Chaque entrée décrit la situation, la conséquence et le résultat souhaité. Une capture peut aider, mais elle doit être accompagnée d’une explication. « Modifier ce bouton » ne dit pas si l’on corrige une erreur, un obstacle d’usage ou une préférence.
Alice demande un bouton pour prolonger un prêt. Étienne s’y oppose parce qu’une réservation peut déjà suivre. Maya reformule le besoin : prolonger seulement si la nouvelle date ne bloque aucune réservation confirmée. La discussion aboutit à une règle, plutôt qu’à une alternance de demandes où chacun annule le travail du précédent.
Classez les demandes selon la conséquence observée : ce qui bloque ou fausse une opération, ce qui rend le parcours difficile, puis les améliorations qui peuvent attendre. Ajoutez la décision et sa raison. Une idée reportée reste visible, sans être promise pour la semaine suivante ni réintroduite à chaque conversation.
Avant une modification, faites préciser les parcours touchés et les essais à reprendre. Le guide pour diriger un projet d’application complète cette organisation. Décider moins de choses à la fois permet surtout de savoir quelle modification a produit le résultat que vous examinez.
8. Séparer participation au projet et usage de l’application
Construire ensemble peut signifier observer une démonstration, annoter un document ou essayer une version. Cela n’impose pas que chaque personne utilise l’outil de création ou envoie directement des instructions aux agents. Choisissez le mode de participation qui convient à ses responsabilités, à sa disponibilité et aux fonctions réellement disponibles.
Maya pourrait conduire la construction depuis son ordinateur, puis préparer une séance d’essai pour Alice et Étienne. Les retours rejoignent le dossier commun avant qu’une nouvelle demande parte. Ce fonctionnement peut convenir à une petite équipe tant que l’absence de Maya ne rend pas les documents et les décisions introuvables.
L’application finale doit, elle, prévoir les appareils et les lieux d’usage : accueil, réserve, domicile éventuel. Faites préciser comment chacun s’y connecte et comment les informations sont partagées. Une application construite sur un ordinateur local ne devient pas automatiquement une application utilisable à plusieurs, ni une solution sans service central.
Essayez les véritables conditions matérielles avec des données fictives : petit écran, connexion instable, personne qui arrive après une semaine d’absence. Notez ce qui manque pour reprendre le travail sans explication orale. Ces observations sont souvent plus utiles qu’une discussion abstraite sur le nombre de personnes théoriquement accepté par l’outil.
9. Mener un pilote avec une règle de référence
Choisissez une période limitée et quelques utilisateurs représentatifs. Précisez où se trouvent les réservations qui font foi. Au début, le collectif peut travailler sur une copie fictive pour valider les parcours. Lors d’un essai réel, il doit décider où saisir chaque information et comment éviter deux listes contradictoires.
Fixez un responsable de l’essai, un canal pour signaler un problème et les conditions d’arrêt. Une double réservation inexpliquée bloque la suite. Un libellé peu clair demande une correction. Une préférence de couleur peut attendre. Ces critères évitent que la décision finale dépende seulement de l’enthousiasme de la personne qui a construit.
- Alice réserve un outil disponible et retrouve sa confirmation.
- Étienne essaie de confirmer une réservation incompatible et reçoit le refus attendu.
- Un outil rendu en retard reste correctement identifié.
- Une personne reprend le dossier après l’absence d’un collègue.
- Une erreur est corrigée et le résultat est visible pour les personnes concernées.
Conservez le résultat de chaque essai, avec le contexte et la version examinée. Après une correction, reprenez les parcours touchés. Avant d’élargir le pilote, demandez aux utilisateurs ce qu’ils font encore ailleurs pour terminer leur tâche : un carnet parallèle peut révéler une information manquante, ou une règle que l’application n’a pas encore comprise.
10. Préparer les absences, les incidents et l’entretien
Une application interne devient vite un point de passage obligé. Décrivez ce que l’équipe fait si elle ne peut plus l’ouvrir, si une information paraît fausse ou si la personne habituelle est absente. Une procédure courte doit permettre de continuer prudemment, de signaler le problème et de retrouver les saisies effectuées pendant l’interruption.
Dans notre exemple, Maya prépare une feuille de secours numérotée pour les prêts autorisés pendant une panne. Le collectif précise qui peut l’utiliser et qui reprendra ces mouvements ensuite. Ce dispositif fictif doit être adapté et testé : noter des prêts sur papier ne résout rien si personne ne les rapproche des réservations existantes.
Nommez la personne ou le prestataire qui entretient le logiciel, les horaires de disponibilité attendus et le mode de demande d’intervention. Conservez les consignes de reprise et les accès dans un emplacement adapté. Une autre personne autorisée doit savoir les retrouver, sans dépendre de messages éparpillés dans plusieurs conversations.
Prévoyez un budget d’entretien et du temps pour les essais après correction. La différence entre prototype et application utilisable devient particulièrement visible lorsque plusieurs personnes dépendent du même outil. La fin de la construction n’est pas la fin des décisions à prendre ensemble.
11. Mesurer ce qui a changé dans le travail
Avant le pilote, choisissez quelques observations simples : réservations qu’il faut corriger, informations ressaisies et demandes qui nécessitent d’appeler un collègue. Gardez la même définition pendant l’essai. Vous pourrez comparer les situations sans inventer un gain de productivité à partir du seul fait que l’interface paraît plus moderne.
Demandez à Alice de montrer comment elle prépare une permanence, puis à Étienne comment il vérifie les retours. Où cherchent-ils encore une réponse ? Quelle information ne leur inspire pas confiance ? Notez les explications. Un outil peut réduire une tâche visible tout en ajoutant un contrôle manuel moins visible à quelqu’un d’autre.
Le temps de l’équipe entre dans le bilan : description des règles, préparation des données, essais, formation et corrections. Si Maya économise une ressaisie mais consacre toutes ses permanences à expliquer l’application, le problème n’est pas encore résolu. Cette observation donne une priorité de correction, pas nécessairement une raison d’abandonner le projet.
12. Préparer le dossier à remettre aux agents ou au prestataire
Réunissez la phrase de besoin, les rôles, les états, les droits et les essais dans un document commun. Ajoutez les décisions reportées et les limites acceptées. Demandez à un collègue de retrouver seul la règle d’une réservation en conflit. Si la réponse reste uniquement dans une conversation, le dossier mérite encore une courte mise au propre.
Vous pouvez partir du modèle gratuit de cahier des charges. Décrivez une demande à la fois, puis réclamez une explication du comportement proposé avant de la faire construire. Les agents peuvent aider à préparer les documents et le code ; les personnes de l’équipe restent responsables des choix métier et de leur validation.
Maestro permet de conduire un projet avec des agents IA sur Mac. Cela ne constitue pas une promesse de coédition simultanée entre collègues : votre organisation de travail et les capacités partagées de l’application finale doivent être définies et vérifiées. Commencez par un pilote porté par une personne qui rassemble les contributions de l’équipe.
Au 23 septembre 2026, Maestro est en beta sur invitation pour macOS 13 et versions ultérieures. L’application est gratuite pendant cette beta, avec l’usage IA facturé séparément ; Windows est en développement. Le premier résultat à viser pour votre équipe reste simple : terminer un passage de relais avec les mêmes informations et une règle que chacun comprend.