Quand un cabinet finit une mission, le moment du départ est presque toujours mal géré. Soit le prestataire s’évapore avec la connaissance dans la tête, soit le client se retrouve dépendant sans s’en rendre compte. Soit, plus rarement, on fait correctement le travail qu’on appelle “sortie de mission”.
Cet article décrit ce que nous avons mis en place chez Cœur du Web pour que la sortie soit un moment cadré, pas un moment improvisé.
Pourquoi la sortie de mission est un sujet sensible
Trois raisons rendent ce moment difficile.
Le prestataire a peu d’intérêt à le préparer. Plus le client est dépendant, plus le prestataire a de chances d’être rappelé. C’est mécanique. Sans discipline contraire explicite, la dépendance s’installe.
Le client ne demande pas la sortie en début de contrat. Au moment de signer, on parle livraison et démarrage, pas fin de mission. Quand la question vient à la fin, il est tard pour bien la traiter.
La documentation prend du temps. Bien documenter une stack qu’on vient de construire prend des jours. Pendant ces jours, on ne livre pas autre chose. C’est un coût caché qui n’est pas dans le scope d’une mission “normale”.
Conséquence : sans clause contractuelle dédiée, la sortie est mal faite. Le client part avec un système qu’il ne maîtrise pas et un prestataire qu’il doit garder pour ne pas tout casser.
Notre clause de sortie de mission
Dans chacun de nos contrats au forfait (CTO externalisé, Pôle IA externalisé, développement sur-mesure), nous insérons une clause de sortie de mission qui couvre quatre obligations contractuelles :
1. Documentation complète remise
Au moment de la sortie, on remet :
- la documentation technique des systèmes construits (architecture, choix techniques, points de vigilance)
- la documentation opérationnelle (procédures de mise à jour, gestion des incidents, journaux à surveiller)
- la documentation métier (règles de gestion implémentées, paramétrages spécifiques)
- le journal des décisions clés prises pendant la mission, avec le pourquoi
Tout est lisible par un développeur ou un responsable technique qui n’a pas participé à la mission. Le test est simple : on doit pouvoir confier la suite à un nouveau prestataire qui s’y retrouve en moins d’une semaine.
2. Formation d’un référent interne
Dès le démarrage de la mission, nous identifions avec le client un référent interne qui sera formé à la suite. Au minimum, un demi-jour de formation par mois pendant la mission. À la sortie, deux à trois journées de transfert opérationnel.
Le référent n’a pas besoin d’être un développeur. Pour une mission CTO externalisé en PME sans équipe tech, c’est souvent un opérationnel motivé qui pilote ensuite les prestataires.
3. Transfert complet des accès
À la sortie, nous transférons :
- les comptes administrateurs des outils tiers (hébergeur, registrar, fournisseurs de service)
- les clés d’accès et tokens des intégrations
- les dépôts de code source sur le compte du client
- les comptes de service créés pour la mission
Et nous supprimons nos propres accès. Pas par paranoïa : par discipline. À la fin, vous opérez seuls, et nous ne pouvons plus rien casser par erreur.
4. Période de garantie courte
Entre la sortie et 30 jours après, nous restons joignables pour les questions sur ce que nous avons livré. Pas pour faire de nouvelles missions, pour répondre à des questions sur la passation. C’est gratuit et inclus dans le contrat.
Au-delà de 30 jours, si vous voulez nous rappeler pour une nouvelle mission, on est ravis. Mais la sortie est terminée.
Pourquoi on le fait alors que ça nous coûte
La question revient régulièrement : pourquoi un cabinet ferait-il ça ? Ça ne va pas dans son intérêt commercial.
Trois raisons.
Réputation longue. Les clients qui ne se sentent pas piégés à la fin d’une mission reviennent quand ils ont un nouveau besoin. Les autres ne reviennent jamais, et préviennent leur réseau.
Fierté professionnelle. Construire un système qui ne tient que parce qu’on l’opère est une mauvaise façon de travailler. Construire un système qui tient sans nous est une fierté.
Cadrage facilité. Quand on sait dès le démarrage qu’on doit pouvoir sortir proprement, on prend de meilleures décisions techniques. On choisit des stacks documentées, des architectures lisibles, des outils standards. Le travail est meilleur.
Ce qu’on ne fait pas
Pour être clair sur ce qu’on n’inclut pas dans la sortie de mission :
Pas de garantie illimitée. Au-delà des 30 jours, si quelque chose casse, c’est une nouvelle prestation. C’est honnête.
Pas de hotline 24/7 gratuite. Pendant les 30 jours, on répond aux questions par email en journée. Pas la nuit, pas le week-end.
Pas de re-formation après six mois. Si votre référent interne quitte l’entreprise un an plus tard, c’est à vous de re-former son successeur, ou de nous rappeler en nouvelle mission.
Comment ça se traduit dans le contrat
Pour les clients qui s’intéressent au formalisme, voici l’extrait standard de nos contrats sur ce sujet (sans les paragraphes administratifs autour) :
Cœur du Web s’engage à fournir, dans les quinze jours précédant le terme de la mission : (i) la documentation complète des systèmes livrés, (ii) une formation opérationnelle d’au moins deux jours à un référent désigné par le Client, (iii) le transfert intégral des accès, comptes et codes sources nécessaires à l’exploitation, (iv) une période de garantie de 30 jours calendaires pendant laquelle Cœur du Web répondra par email, en jours ouvrés, aux questions du Client liées à la passation.
C’est court, c’est explicite, c’est engageant.
Le piège qu’on évite
L’erreur que beaucoup de cabinets font sur ce sujet : promettre la sortie en signature, et la bâcler à la fin. La cause est presque toujours la même : on a mal cadré le budget de la mission, on s’est retrouvé en retard, et la sortie est devenue la variable d’ajustement.
Notre méthode pour éviter ça : la sortie est une livraison contractuelle au même titre que les autres. Elle a son budget, son calendrier, ses critères de recette. Si on tape dedans pour rattraper du retard, on n’est plus payé. C’est un garde-fou simple et efficace.
Pour aller plus loin
- CTO externalisé : la mission type où cette clause s’applique systématiquement
- Forfait ou régie : pourquoi on a arrêté la régie en 2026 : la discipline du forfait dont la sortie de mission est un pilier
- Pourquoi on a tout révisé en 2026 : le pivot complet de notre modèle
- Comment on documente une mission pour qu’elle survive à notre départ : la méthode concrète derrière cette discipline
- Qui est propriétaire du code de votre logiciel sur mesure : les quatre clauses à vérifier avant de signer
- Cadrer un mandat de management de transition : la condition de sortie s’écrit avant, pas après
- Livrer une plateforme, puis livrer les gens qui sauront la faire tourner : la transmission poussée jusqu’à la formation d’une équipe