Transmission du logiciel Guide du responsable métier
Comment remettre un logiciel sur mesure à son équipe ?
Préparez trois choses avant de réunir vos collègues : des accès qui fonctionnent, une démonstration sur un vrai cas de leur travail et un kit de démarrage qu’ils garderont sous la main. Restez ensuite disponible les premiers jours et vérifiez, avec quelques questions précises, que chacun fait réellement son travail dans l’application avant d’arrêter l’ancienne façon de faire.
- AvantPréparerTrancher cinq questions, créer et tester les accès, annoncer la date.
- Le jour de la remiseMontrer, puis faire faireUn cas réel de bout en bout, chacun sur son poste, kit remis à la fin.
- Les premiers joursÉcouter et vérifierRépondre vite, poser les bonnes questions, puis fermer l’ancien outil.
Votre rôle : faire adopter l’outil, pas le maintenir
Vous avez porté le projet, vous connaissez le métier, et c’est vous que vos collègues interrogeront. Cette page vous concerne si l’application vient d’être livrée et que vous devez maintenant la faire entrer dans le travail de l’équipe.
Ce qui vous revient
- Expliquer pourquoi l’équipe change de façon de travailler.
- Organiser les accès et la démonstration.
- Remettre un kit de démarrage clair.
- Recueillir les questions et les difficultés des premiers jours.
- Décider quand l’ancien fichier ou l’ancien outil s’arrête.
Ce qui ne vous revient pas
- Récupérer et contrôler le code, les comptes techniques et la documentation : c’est la passation avec le prestataire.
- Organiser la reprise de la maintenance : voir le transfert par paliers.
- Construire un programme de formation par rôle : voir la formation de handover.
- Piloter le calendrier complet du transfert : voir les sept étapes.
Avant de réunir l’équipe : cinq questions à trancher
Vos collègues vous les poseront, souvent dans les premières minutes. Si vous n’avez pas la réponse, la démonstration tourne au débat.
Pourquoi cet outil, pour nous ?
Une phrase sur le problème concret qu’il règle dans leur travail : les ressaisies, les relances, le fichier que deux personnes modifient en même temps. Pas la liste des fonctions.
Qu’est-ce qui change dans ma journée ?
Deux ou trois changements par poste : où l’on saisit, qui valide, où l’on retrouve une information. Ce qui ne change pas mérite aussi d’être dit.
Qu’est-ce qui s’arrête, et quand ?
L’ancien fichier, le formulaire papier, la boîte mail partagée. Fixez la date à partir de laquelle il passe en lecture seule, sinon les deux circuits coexistent.
Qui répond à mes questions ?
Un nom, un canal et des horaires réalistes. Si c’est vous, prévoyez le temps dans votre agenda des premiers jours.
Et si l’application ne répond plus ?
Qui prévenir, quoi faire en attendant, comment rattraper la saisie ensuite. La réponse se vérifie auprès de la personne chargée de la maintenance.
Préparer les accès avant la démonstration
Une démonstration qui commence par vingt minutes de mots de passe oubliés est une démonstration perdue. Les comptes se créent en amont, un profil après l’autre.
| Profil | Ce qu’il peut faire | Qui | Connexion testée |
|---|---|---|---|
| Saisie | Créer et compléter un dossier | [Noms] | [Date] |
| Validation | Valider, refuser, renvoyer pour correction | [Noms] | [Date] |
| Consultation | Rechercher et lire, sans modifier | [Noms] | [Date] |
| Administration | Gérer les comptes et les listes | [Deux noms] | [Date] |
- Un compte par personne. Pas d’identifiant partagé « équipe », qui empêche de savoir qui a fait quoi.
- Une connexion testée par profil avant la réunion, avec un vrai compte de ce profil, pas seulement le vôtre.
- Aucun mot de passe en réunion ni par message collectif : chacun active son compte avec le lien reçu.
- Deux administrateurs, pour qu’une absence ne bloque pas l’arrivée d’un collègue.
La démonstration : leur travail, pas les menus
Le réflexe est de faire le tour de l’application, écran par écran. Vos collègues retiendront mieux un seul dossier traité de bout en bout, puis le leur, sur leur propre poste.
- Rappeler le point de départ. Le problème que l’équipe connaît, dans ses mots. Une minute suffit si l’annonce a été envoyée.
- Traiter un cas réel de bout en bout. Un dossier ordinaire, apporté par un collègue, du premier écran au dernier. Montrez la règle métier quand elle intervient, pas avant.
- Montrer ce qui disparaît. La ressaisie, la relance par mail, la version « finale_v3 » du fichier. C’est souvent ce qui convainc.
- Faire faire. Chacun traite un dossier d’essai sur son poste, avec ses accès. Vous circulez, vous ne prenez pas la souris.
- Montrer où trouver de l’aide. La fiche de démarrage, les guides, le canal de questions. Faites-le après la pratique, quand les questions sont concrètes.
- Recueillir les inquiétudes. Notez-les sans débattre en séance. Celles qui reviennent iront dans les questions fréquentes du kit.
À éviter pendant la démonstration
- Une démonstration sur des données parfaites : prévoyez au moins un cas incomplet ou une exception.
- Promettre une évolution en séance : notez la demande, elle sera arbitrée plus tard.
- Laisser l’ancien fichier ouvert « au cas où » sans date d’arrêt.
Le kit de remise
Ce que chaque collègue reçoit à la fin de la démonstration, et retrouve ensuite au même endroit : un dossier partagé, une page d’intranet ou un message épinglé dans le canal de l’équipe. Pour le contenu des supports selon les rôles, voyez les supports de formation par rôle.
- Le lien et l’identifiantAdresse de l’application, rappel de l’identifiant, procédure en cas de mot de passe oublié.
- La fiche de démarrageUne page : vos tâches, ce qui change, qui appeler. Exemple ci-contre.
- Les guides par tâcheUn guide court pour chaque tâche courante, rangés par poste.
- Le contact et le canalLe nom du référent, le canal de questions, les heures où il répond.
- Le calendrier de basculeDate de démarrage, date de passage en lecture seule de l’ancien outil.
- Les questions fréquentesCelles de la démonstration, avec leur réponse, complétées au fil des jours.
- Un espace d’essaiSi l’application en dispose : des dossiers fictifs pour s’exercer sans risque.
- La conduite en cas de panneQui prévenir, quoi noter en attendant, comment rattraper la saisie.
Exemple fictif
Fiche de démarrage · Suivi des réclamations clients
- Votre accès
- [adresse de l’application] · identifiant : votre adresse professionnelle
- Vos trois tâches
- Enregistrer une réclamation reçue · Joindre les pièces · Proposer une réponse au valideur
- Ce qui change
- Plus de tableau partagé : chaque réclamation a un dossier et un statut visible de tous.
- En cas de doute
- Guide « Enregistrer une réclamation » · canal #reclamations-app · [nom du référent]
- Bascule
- Démarrage le [date] · le tableau partagé passe en lecture seule le [date]
Les questions à vérifier avec l’équipe
Poser « c’est clair pour tout le monde ? » n’apprend rien. Ces questions appellent une réponse vérifiable. Une réponse négative n’est pas un échec : elle indique quoi faire ensuite. Pour organiser l’accompagnement lui-même, jusqu’au premier cycle complet, reprenez la frise des premières utilisations de l’article sur la formation.
1 À la fin de la démonstration
- Chacun s’est-il connecté avec son propre compte ?
- Sinon : réglez l’accès le jour même, pas « la semaine prochaine ».
- Chacun a-t-il traité un dossier d’essai sans aide ?
- Sinon : proposez un court créneau à deux avec la personne concernée.
- Tout le monde sait-il où se trouve le kit ?
- Sinon : épinglez-le dans le canal de l’équipe.
- Quelle tâche vous inquiète le plus ?
- Les réponses désignent les guides à écrire ou à revoir en priorité.
2 Après les premiers jours d’usage
- Quelle tâche vous prend plus de temps qu’avant ?
- Une lenteur réelle se signale au prestataire ou au mainteneur ; une hésitation se règle par un guide.
- Avez-vous saisi quelque chose deux fois, ici et ailleurs ?
- Une double saisie annonce un retour à l’ancien outil. Cherchez ce qui manque.
- À qui avez-vous posé vos questions ?
- Si c’est toujours au même collègue, il est devenu le support : reconnaissez-le, ou redirigez vers le canal.
- Y a-t-il un cas que l’application ne sait pas traiter ?
- Notez-le avec un exemple réel. Il alimente la liste des évolutions, à arbitrer.
3 Avant d’arrêter l’ancien outil
- Les dossiers en cours ont-ils tous été repris dans l’application ?
- Sinon : fixez qui les reprend, et décalez l’arrêt si nécessaire.
- Chaque poste a-t-il réalisé ses tâches courantes dans l’application ?
- Vérifiez-le dans l’application elle-même, pas sur déclaration.
- L’ancien outil est-il encore modifié ?
- Si oui, cherchez pourquoi avant de le fermer, plutôt que de le fermer d’autorité.
- Les absents de la démonstration ont-ils été accompagnés ?
- Les arrivants et les personnes à temps partiel sont les plus souvent oubliés.
Les signes d’une remise qui patine
- Un fichier parallèle réapparaît, « juste pour suivre ». L’application ne montre sans doute pas une information dont l’équipe a besoin.
- Les questions passent en messages privés. Les réponses ne profitent qu’à une personne et le kit ne s’enrichit pas.
- Une personne saisit pour les autres. L’outil est utilisé, mais pas adopté : la dépendance s’est déplacée.
- Les contournements se multiplient : champs détournés, commentaires utilisés comme statuts. Ils montrent où l’outil ne colle pas au travail réel.
Aucun de ces signes n’est grave s’il est repéré tôt. Il se traite par un guide, un réglage ou une petite évolution, à condition que quelqu’un le remonte.
Ce que prévoit un projet Mexar
Avec la méthode ROI-first, l’application est construite avec les personnes qui l’utiliseront : la démonstration à l’équipe ne devrait pas arriver comme une découverte. Le parcours prévoit un accompagnement à la prise en main ; sa durée et son périmètre sont fixés dans le devis, selon l’application et votre équipe.
Vous recevez aussi le code, une documentation rédigée pour être reprise par un développeur comme par un assistant IA, et la maîtrise des services tiers utilisés. Votre rôle de responsable reste celui décrit ici : faire entrer l’outil dans le travail de vos collègues.