MexarTransférer un logiciel sur mesure à votre équipe : par paliers, jusqu’à l’autonomie vérifiée
Transférer un logiciel sur mesure ne se fait pas en un rendez-vous. Votre équipe reprend les opérations une à une, en passant par quatre paliers : observer, faire ensemble, faire sous contrôle, faire seule. Le transfert est terminé quand les opérations importantes sont réalisées par vos équipes, sans le prestataire, et que des preuves le montrent. La remise des fichiers n’est qu’un point de départ.
Par François Aubeut, fondateur de Mexar ·
Remise des fichiers et transfert : deux choses différentes
La remise
Un moment. Le prestataire livre le code, les accès et la documentation. On la vérifie par une checklist de contrôles datés.
Elle répond à la question : avez-vous tout reçu ?
Le transfert
Une période. Votre équipe apprend à faire elle-même ce que faisait le prestataire, et le prouve sur des cas réels.
Il répond à la question : pouvez-vous continuer sans lui ?
La remise et sa checklist de réception sont détaillées dans notre article sur la passation d’un logiciel interne. Ici, nous traitons ce qui vient ensuite : la reprise progressive du travail.
Le principe
Quatre paliers de responsabilité
Chaque opération progresse à son rythme. Créer un utilisateur est souvent repris vite, alors que restaurer une sauvegarde ou déployer une correction demandera plusieurs passages. L’important est de savoir, pour chaque opération, à quel palier elle se trouve.
-
1 Observer
Le prestataire réalise l’opération devant la personne qui la reprendra, en expliquant pourquoi il fait chaque geste. Elle prend des notes et confronte la documentation à ce qu’elle voit.
Pour passer au palier 2 : la personne sait dire quand l’opération est nécessaire et ce qui peut mal tourner.
-
2 Faire ensemble
Votre collaborateur tient le clavier, le prestataire guide. Les écarts entre la documentation et la réalité sont corrigés au fil de l’eau.
Pour passer au palier 3 : l’opération est menée jusqu’au bout sans que le prestataire touche au clavier.
-
3 Faire sous contrôle
Votre équipe réalise l’opération sur un cas réel. Le prestataire vérifie le résultat après coup et ne l’aide qu’en cas de blocage.
Pour passer au palier 4 : plusieurs exécutions réussies, sur des cas différents, sans correction de sa part.
-
4 Faire seule
L’opération ne fait plus appel au prestataire d’origine. Elle est tenue par votre équipe ou par un tiers que vous avez désigné par écrit, par exemple un autre développeur. Les questions trouvent leur réponse dans la documentation ou auprès d’un collègue.
Preuve : une trace datée (ticket, journal de déploiement, compte rendu) montre l’opération réalisée par son responsable désigné.
Ces paliers décrivent qui tient une opération, entre le prestataire et vous. Ils ne mesurent pas ce qu’une personne sait faire : une opération peut être au palier 4 alors qu’un collègue débute encore. Les acquis individuels se vérifient rôle par rôle, comme nous le décrivons dans l’article sur la formation de handover d’un logiciel personnalisé.
Outil
Situez chacune de vos opérations
Voici les opérations qu’un transfert doit couvrir dans la plupart des applications métier, avec la preuve qui permet de les considérer comme reprises. Indiquez le palier atteint pour chacune. La synthèse en bas de la grille liste celles qui dépendent encore du prestataire d’origine, ou qui n’ont pas encore de responsable autonome désigné. Rien n’est enregistré ni envoyé.
Après la livraison
Organiser la reprise de la maintenance
Tout ne doit pas forcément revenir en interne. Le transfert sert à ce que vous choisissiez qui maintient l’application, au lieu de subir ce choix. Trois organisations sont courantes ; chacune demande une préparation différente.
Distinguez trois natures de maintenance, qui n’appellent pas les mêmes compétences : corrective (une anomalie à corriger), de sécurité (dépendances et services à mettre à jour) et évolutive (un nouveau besoin). La dernière suppose aussi quelqu’un qui décide, côté métier, de ce qui vaut la peine d’être développé.
Accompagnement
Un accompagnement utile prévoit sa propre fin
L’accompagnement aide l’équipe à franchir les paliers 3 et 4. Mal cadré, il les empêche : l’équipe garde le réflexe d’appeler le prestataire au lieu de chercher la réponse.
- Un seul canal pour les questions, partagé avec l’équipe, plutôt que des appels individuels.
- Un journal des questions : chaque réponse alimente la documentation interne.
- Un rôle qui diminue : le prestataire passe de l’exécution à la vérification, puis à la simple réponse.
- Une fin explicite, fixée par une date ou par l’atteinte des critères ci-dessous.
Clôture
Critères observables de fin de transfert
Le transfert est terminé lorsque ces faits sont constatés et datés. Chacun s’observe : il ne repose pas sur l’impression que « tout le monde a compris ».
Ce qui prouve la fin du transfert
- Les opérations courantes ont été réalisées au moins une fois au palier 4, par votre équipe ou par le tiers désigné, avec une trace.
- Une sauvegarde a été restaurée par vos soins dans un environnement de test.
- Une correction a été déployée en production par la personne chargée de la maintenance.
- Les questions des utilisateurs trouvent leur réponse en interne.
- Chaque compte et chaque service tiers est au nom de l’entreprise, avec deux administrateurs.
- La documentation a été corrigée par votre équipe là où elle était fausse ou incomplète.
- Les opérations rares (incident majeur, changement d’hébergement) ont une procédure relue par un membre de l’équipe.
Ce qui ne la prouve pas
- La remise d’une archive du code.
- Une réunion de présentation de l’application.
- Un procès-verbal signé sans contrôle réalisé par l’équipe.
- L’absence de questions pendant une semaine calme.
- Une date de fin de contrat atteinte.
Exemple fictif
À quoi ressemble un transfert par paliers
Cas inventé pour illustrer la méthode : une PME de maintenance industrielle reçoit une application de suivi des demandes d’intervention. Trois opérations, trois rythmes différents.
| Opération | Début | Milieu | Fin du transfert |
|---|---|---|---|
| Créer un technicien et ses droits | Palier 2 | Palier 4 | Palier 4, fait trois fois par l’assistante d’exploitation |
| Importer le catalogue de pièces | Palier 1 | Palier 3 | Palier 4, après un import raté puis corrigé en interne |
| Déployer une correction | Palier 1 | Palier 2 | Palier 4, tenu par un développeur externe désigné par écrit, qui a déployé seul une correction |
Dans la dernière ligne, l’entreprise a choisi de ne pas internaliser le déploiement. Elle l’a confié à un développeur externe, qui a montré qu’il savait le faire seul à partir de la documentation. L’opération ne dépend plus du prestataire d’origine : elle est au palier 4. Le transfert est terminé parce que chaque opération a un responsable désigné et capable, pas parce que tout est fait en interne.
Chez Mexar
Comment nous préparons le transfert
Avec la méthode ROI-first, l’application est construite avec vos équipes, ce qui prépare le transfert dès le départ. À 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. Vous restez libre de poursuivre avec nous ou avec un autre développeur.
Le parcours inclut un accompagnement à la prise en main. Sa durée et son périmètre sont définis dans le devis, selon l’application et l’organisation de votre équipe.