Transmission du logiciel Parcours opératoire
Quelles étapes pour transférer un logiciel personnalisé à l’équipe ?
Sept étapes, dans cet ordre : cadrer, faire l’état des lieux, planifier, transférer les accès, transmettre les savoirs, exploiter avec appui, puis réceptionner. Chacune part d’entrées connues, a un responsable désigné, produit un livrable et se termine par un point de contrôle. Tant que ce contrôle n’est pas constaté, on ne passe pas à l’étape suivante.
Cette page décrit le déroulé dans le temps. Elle s’adresse à la personne qui pilote le transfert côté entreprise et doit préparer une transition réelle : quoi lancer en premier, qui mobiliser, quoi exiger à la fin de chaque étape.
Les autres articles de la série détaillent le contenu de certaines étapes : l’inventaire et la checklist de réception dans la passation d’un logiciel interne, la reprise opération par opération dans le transfert par paliers, et les sessions par rôle dans la formation de handover.
Qui tient l’application, à chaque étape
Le transfert commence et finit côté entreprise. Le prestataire mène l’état des lieux, puis le travail se fait à deux avant que votre équipe n’opère seule.
Le parcours, étape par étape
Pour chaque étape : ce qu’il faut avoir en main, qui la porte, ce qu’elle produit, et le contrôle qui ouvre l’étape suivante.
-
Étape 1 Préparation
Cadrer le transfert
Un transfert sans date ni critères ne se termine jamais : il s’étiole. Cette première étape décide qui reprend quoi, pour quand, et ce qui permettra de dire que c’est fait.
- Entrées
- Le contrat ou le devis (clauses de cession des droits, d’accompagnement, de fin de mission), la liste des personnes qui utilisent l’application, l’organisation de maintenance envisagée.
- Responsable
- Le référent interne qui pilotera le transfert, sous l’arbitrage du sponsor métier. Le prestataire est consulté.
- Livrables
- Une note de cadrage courte : périmètre (application, données, services tiers), rôles cibles nommés avec leurs suppléants (administrateurs, mainteneur, référent des utilisateurs), date visée pour la réception, critères de réception écrits.
- Contrôle pour passer à l’étape 2
- Chaque rôle cible porte un nom. Les critères de réception sont écrits et le prestataire les a lus et acceptés.
-
Étape 2 Préparation
Faire l’état des lieux
On ne transfère bien que ce que l’on a listé. Le prestataire est le mieux placé pour dresser l’inventaire ; votre équipe, pour repérer ce qui y manque.
- Entrées
- L’application en service, les accès existants, la documentation disponible, les tâches que le prestataire réalise aujourd’hui sans que personne ne les voie.
- Responsable
- Le prestataire rédige. Le référent et le futur mainteneur relisent.
- Livrables
- Un inventaire : code et version en production, comptes et services tiers (titulaire, payeur, échéances), documents existants, opérations récurrentes avec leur fréquence et la personne qui les fait aujourd’hui, anomalies connues. Le détail de ce qu’il doit contenir figure dans l’article sur la passation d’un logiciel interne.
- Contrôle pour passer à l’étape 3
- Le futur mainteneur a relu l’inventaire et signalé ses manques. Aucune opération récurrente connue de l’équipe n’en est absente.
-
Étape 3 Préparation
Planifier
Le plan transforme l’inventaire en calendrier. Son point le plus fragile n’est pas technique : c’est le temps réellement disponible des personnes qui vont reprendre l’application.
- Entrées
- L’inventaire, les disponibilités de l’équipe, le calendrier métier : périodes chargées, clôtures, saisonnalité.
- Responsable
- Le référent construit le plan. Le sponsor valide le temps dégagé dans les agendas.
- Livrables
- Un plan de transfert : pour chaque opération, qui la reprend, à quelle date et quelle preuve on attend. S’y ajoutent les dates des sessions, la date de bascule des accès et une période sans nouvelle fonctionnalité pendant le transfert.
- Contrôle pour passer à l’étape 4
- Les créneaux sont réservés dans les agendas des personnes concernées. Le plan évite les pics d’activité. Le sponsor l’a validé.
-
Étape 4 Transfert
Transférer les accès
Placez cette étape avant la formation. Votre équipe s’exerce ainsi avec ses propres comptes, et un départ anticipé du prestataire ne bloque plus rien.
- Entrées
- L’inventaire des comptes, les moyens de paiement de l’entreprise, un coffre de mots de passe partagé par l’équipe.
- Responsable
- Le prestataire et l’administrateur interne, ensemble. Le référent répond du résultat.
- Livrables
- Des comptes au nom de l’entreprise et payés par elle, deux administrateurs internes par compte, des secrets techniques renouvelés et rangés, et la liste datée des accès que le prestataire conserve, avec leur justification.
- Contrôle pour passer à l’étape 5
- Deux personnes internes se sont connectées à chaque compte. La facture d’au moins un service tiers est arrivée à l’entreprise, pas au prestataire.
-
Étape 5 Transfert
Transmettre les savoirs
Les sessions servent à faire faire, pas à montrer. Chaque rôle apprend ses propres tâches, sur un environnement d’essai, et la documentation s’améliore à chaque question.
- Entrées
- Le plan, la documentation existante, un environnement d’essai avec des données de test réalistes.
- Responsable
- Le prestataire anime. Le référent organise. Administrateurs et mainteneur pratiquent.
- Livrables
- Des sessions réalisées pour chaque rôle, une documentation corrigée par l’équipe, un journal des questions ouvert. Le contenu de chaque programme est détaillé dans la formation de handover par rôle.
- Contrôle pour passer à l’étape 6
- Chaque personne a réalisé au moins une fois les tâches de son rôle sur l’environnement d’essai. La documentation contient des corrections apportées par l’équipe elle-même.
-
Étape 6 Transfert
Exploiter avec appui
Votre équipe réalise les opérations sur l’application réelle. Le prestataire ne fait plus : il vérifie et répond. C’est l’étape la plus longue, et celle qui prouve que le transfert a eu lieu. Si la recette de l’application n’a pas encore été prononcée, cette exploitation peut être interprétée comme une acceptation : écrivez que cette période fait partie du transfert et consignez vos réserves au fil de l’eau.
- Entrées
- L’application en production, les accès internes, l’appui du prestataire dans les limites convenues.
- Responsable
- Administrateurs et mainteneur exécutent. Le prestataire vérifie après coup.
- Livrables
- Un journal des opérations réalisées par l’équipe (date, personne, résultat), dont au moins une restauration de sauvegarde en environnement de test et une correction déployée. Le journal des questions continue d’alimenter la documentation. La progression opération par opération est décrite dans le transfert par paliers.
- Contrôle pour passer à l’étape 7
- Chaque opération du plan a une trace datée, réalisée par l’équipe sans intervention du prestataire. Les questions des utilisateurs trouvent leur réponse en interne.
-
Étape 7 Clôture
Réceptionner et clore
La réception confronte la réalité aux critères écrits à l’étape 1. Elle date, dans les termes prévus au contrat, le moment où les responsabilités changent de mains.
- Entrées
- Les critères de réception de l’étape 1, le journal des opérations, l’inventaire mis à jour.
- Responsable
- Le référent prépare le dossier. Le sponsor décide.
- Livrables
- Un procès-verbal (acceptation, réserves avec responsable et échéance, ou refus motivé), les accès résiduels du prestataire retirés ou listés, la date de fin de l’accompagnement, et un tableau « qui fait quoi » communiqué aux utilisateurs. La checklist de contrôles est dans l’article sur la passation.
- Contrôle final
- Chaque critère écrit à l’étape 1 est constaté, un par un, avec sa preuve. Ceux qui ne le sont pas deviennent des réserves datées, pas des oublis.
Qui fait quoi : la matrice des responsabilités
Une matrice RACI évite deux pièges classiques : l’étape que tout le monde croit portée par un autre, et l’étape que deux personnes croient diriger. Adaptez les colonnes à votre organisation ; une même personne peut tenir plusieurs rôles.
- R Réalise le travail
- A Répond du résultat et tranche (une seule personne par étape)
- C Consulté avant la décision
- I Informé du résultat
| Étape | Sponsor métier | Référent interne | Administrateur | Mainteneur | Prestataire d’origine |
|---|---|---|---|---|---|
| 1. Cadrer | A | R | I | C | C |
| 2. État des lieux | I | A | C | C | R |
| 3. Planifier | C | A, R | C | C | C |
| 4. Transférer les accès | C | A | R | C | R |
| 5. Transmettre les savoirs | I | A | R | R | R |
| 6. Exploiter avec appui | I | A | R | R | C |
| 7. Réceptionner | A | R | C | C | C |
Le sponsor métier est la personne qui a commandé l’application et arbitre les priorités. Le référent interne pilote le transfert au quotidien. Le mainteneur peut être un collaborateur ou un développeur externe que vous choisissez : dans ce cas, faites-le entrer dès l’étape 2.
Adapter l’ordre à votre situation
L’ordre ci-dessus convient à la plupart des transferts. Quatre situations fréquentes demandent de le modifier, sans supprimer de contrôle.
Le prestataire doit partir vite
Faites les étapes 2 et 4 en priorité : l’inventaire et les accès. Tant que les comptes sont à votre nom et que vous savez ce qui existe, la suite peut se faire avec un autre développeur, même plus tard.
Une seule personne reprend tout
La matrice se resserre, mais elle ne disparaît pas. Nommez un suppléant, même pour quelques opérations seulement, sinon la dépendance a simplement changé de nom.
La maintenance part chez un autre prestataire
Il relit l’inventaire à l’étape 2, suit les sessions techniques à l’étape 5 et réalise lui-même la correction déployée de l’étape 6. Ne l’engagez qu’après cette preuve.
L’application est encore en construction
Menez les étapes 1 à 3 pendant le projet. Un transfert préparé dès le départ coûte moins cher qu’un transfert découvert la dernière semaine.
Votre plan de transfert, prêt à remplir
Reprenez ce modèle dans votre tableur ou votre outil de suivi. Les colonnes « date visée » et « contrôle constaté le » sont les deux dates qui comptent : la première se planifie, la seconde se prouve.
| Étape | Livrable attendu | Responsable | Date visée | Contrôle constaté le |
|---|---|---|---|---|
| 1. Cadrer | Note de cadrage avec rôles nommés et critères de réception | [À compléter] | [À compléter] | [À compléter] |
| 2. État des lieux | Inventaire relu par le futur mainteneur | [À compléter] | [À compléter] | [À compléter] |
| 3. Planifier | Plan validé, créneaux réservés | [À compléter] | [À compléter] | [À compléter] |
| 4. Transférer les accès | Comptes au nom de l’entreprise, deux administrateurs chacun | [À compléter] | [À compléter] | [À compléter] |
| 5. Transmettre les savoirs | Sessions par rôle, documentation corrigée | [À compléter] | [À compléter] | [À compléter] |
| 6. Exploiter avec appui | Journal des opérations réalisées par l’équipe | [À compléter] | [À compléter] | [À compléter] |
| 7. Réceptionner | Procès-verbal, accès résiduels traités, fin d’accompagnement datée | [À compléter] | [À compléter] | [À compléter] |
Nous ne donnons pas de durée type : elle dépend du nombre d’opérations, de la disponibilité de l’équipe et du calendrier métier. Une étape dont le contrôle n’est pas constaté se prolonge ; elle ne se coche pas.
Où se placent ces étapes dans un projet Mexar
Dans la méthode ROI-first, l’application est construite avec vos équipes : le cadrage du transfert et l’état des lieux se préparent pendant la réalisation, pas après. L’accompagnement à la prise en main et la transmission de l’autonomie sont deux étapes prévues du parcours.
À la fin, vous recevez 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. La durée et le périmètre de l’accompagnement sont fixés dans le devis, selon l’application et votre organisation.