Une PME qui dépend d'un seul développeur ne le découvre presque jamais avant son départ. Le jour où il quitte l'entreprise, prend un long congé ou cesse simplement de répondre, l'application qu'il maintenait continue de tourner, mais plus personne ne sait comment ni pour combien de temps. La parade tient en trois conditions, quel que soit votre modèle : le code sur un dépôt qui vous appartient, un manuel d'exploitation qu'un autre développeur peut suivre, des accès nominatifs et révocables. Reste à choisir qui fait tourner l'application. Nous comparons ici le développeur seul, l'équipe interne et le mainteneur externe sur la continuité, la documentation et la sortie.
Le facteur bus : ce qui se passe quand la seule personne qui sait s'en va
Le facteur bus est une image un peu brutale mais utile : combien de personnes doivent disparaître pour que votre projet s'arrête ? Quand la réponse est une, vous portez un risque que peu de dirigeants mesurent avant de le vivre.
Un scénario type, composé à partir de situations que l'on retrouve souvent. Un négociant en matériaux de 60 personnes fait développer par un freelance un portail de commande relié à sa gestion commerciale. Le portail marche bien pendant trois ans, le freelance corrige les petits problèmes en quelques jours et tout le monde est content. Puis il accepte un contrat à plein temps ailleurs. Deux mois plus tard, une mise à jour de l'hébergeur casse la synchronisation des stocks. Les commerciaux saisissent les commandes à la main pendant six semaines, le temps de trouver quelqu'un qui accepte la reprise d'un code dont il n'existe aucune documentation.
Ce qui coûte cher dans cette histoire, ce n'est pas le bug. C'est le délai entre l'incident et le moment où quelqu'un de compétent peut agir. Il se compte en semaines quand le savoir est parti avec une personne, en heures quand il a été transmis. Le même scénario existe avec un salarié : son préavis donne un peu de temps pour organiser le transfert, à condition que quelqu'un y pense.
Les signes que vous êtes déjà dépendant
La dépendance se lit dans des détails techniques que la direction ne regarde pas. Ce sont ceux que nous retrouvons le plus souvent en audit.
Les accès sont personnels. L'hébergement, le nom de domaine, les services tiers et les comptes d'API sont ouverts avec l'adresse e-mail du développeur, parfois son adresse personnelle. Si son compte disparaît, l'entreprise n'a plus la main sur sa propre infrastructure.
Le dépôt de code est sur son compte. Le code source vit dans un espace GitHub ou GitLab qui lui appartient. L'entreprise y a peut-être un accès en lecture, souvent aucun. Dans le pire des cas, le code n'existe que sur son ordinateur portable.
Il n'y a pas de manuel d'exploitation. Personne d'autre que lui ne sait déployer une nouvelle version, relancer un service tombé, restaurer une sauvegarde ou renouveler un certificat. Ces gestes sont dans sa tête, pas dans un document.
Les secrets ne sont pas centralisés. Les mots de passe de base de données et les clés d'API sont dans un fichier local ou une conversation de messagerie.
Personne ne peut estimer une modification. Quand la direction demande combien de temps prendrait un nouvel écran, une seule personne peut répondre, et personne ne peut vérifier sa réponse.
Si trois de ces cinq signes sont présents, vous êtes dépendant. Ce n'est pas un jugement sur le développeur, qui peut être excellent. C'est un constat sur l'organisation autour de lui, et le premier des coûts cachés d'une application non maintenue.
Comparatif un : le développeur seul, rapide mais fragile
Le développeur unique, freelance ou salarié, reste la solution la plus répandue dans les PME, et pour de bonnes raisons. Il coûte moins cher qu'une équipe, il connaît le métier parce qu'il a tout construit, et il décide vite. Un besoin exprimé le lundi peut être en production le jeudi.
Continuité. C'est le point faible. Un arrêt maladie, des vacances ou un départ suspendent toute capacité d'intervention. Aucune supervision ne tourne en dehors de lui : les erreurs sont détectées quand un utilisateur se plaint.
Documentation. Elle existe rarement, non par négligence mais par absence de lecteur. Le code est souvent propre, les procédures d'exploitation sont absentes.
Sortie. Elle dépend de sa bonne volonté et du temps disponible avant son départ. Quand la relation se termine brutalement, l'entreprise part de zéro.
Cette option convient à un outil non critique, remplaçable par un logiciel du marché en quelques semaines, ou à une phase de démarrage où la vitesse compte plus que la robustesse. Elle devient dangereuse dès que l'application porte du chiffre d'affaires ou bloque une équipe quand elle tombe.
Comparatif deux : l'équipe interne, quand elle est possible et ce qu'elle exige
Recruter une seconde personne, puis une troisième, résout le facteur bus sur le papier. Deux développeurs qui travaillent sur le même code se relisent, partagent les accès et couvrent les absences l'un de l'autre. C'est l'organisation la plus solide quand elle est bien menée.
Continuité. Bonne, à condition que les deux personnes travaillent réellement sur le même périmètre. Une équipe de deux où chacun a son application reproduit deux dépendances au lieu d'une.
Documentation. Elle progresse naturellement, parce qu'il y a enfin un lecteur. Les revues de code, les conventions partagées et les procédures écrites apparaissent quand plusieurs personnes doivent se coordonner.
Sortie. Le départ d'un membre ne fait plus tout tomber. Il reste néanmoins coûteux : il faut recruter, former, et l'équipe tourne à effectif réduit pendant plusieurs mois.
Le coût réel dépasse les salaires. Une PME de 80 personnes qui embauche deux développeurs pour maintenir un seul outil paie deux salaires chargés pour une charge qui n'occupe pas deux personnes à plein temps. Il faut aussi les manager : sans responsable technique, deux développeurs produisent des choix contradictoires. Pour un projet neuf plutôt qu'une maintenance, nous avons posé le même calcul dans agence IA ou recrutement interne.
L'équipe interne a du sens quand l'application est au centre de l'activité, évolue chaque semaine et que l'entreprise a la taille pour absorber le coût fixe. En dessous, on paie une assurance très chère.
Comparatif trois : le mainteneur externe, une équipe d'exploitation et un référent
La troisième option consiste à confier la maintenance à un prestataire dont c'est le métier, avec une équipe qui assure l'exploitation au quotidien et un référent qui connaît votre contexte. Le savoir n'est plus porté par une personne mais par une organisation.
Continuité. C'est le point fort, à condition de vérifier ce qu'il y a derrière le mot. Un bon mainteneur met en place une supervision continue, détecte les erreurs avant que vos utilisateurs ne les signalent et s'engage par écrit sur des délais de réaction, définis au contrat après un audit. Le référent qui vous suit a un remplaçant.
Documentation. Le prestataire y a un intérêt direct : il ne peut pas faire tourner votre application à plusieurs sans procédures écrites. La reprise commence d'ailleurs par une phase de documentation qui produit le manuel d'exploitation que vous n'aviez pas.
Sortie. C'est le critère à examiner avant de signer. Un prestataire sérieux travaille sur votre dépôt, avec vos comptes, et vous remet un rapport d'activité régulier. Si vous voulez changer de mainteneur ou internaliser dans deux ans, tout est chez vous. Si le contrat prévoit que le code, les accès ou l'hébergement restent chez lui, vous avez remplacé une dépendance par une autre.
Cette option convient à la PME ou l'ETI dont l'application est critique mais n'évolue pas assez pour occuper une équipe interne, et à celles qui ont déjà vécu un départ. Elle a un coût mensuel, mais il est connu à l'avance, ce qui n'est le cas ni du freelance qui facture à l'incident ni du recrutement qui échoue.
Ce qui doit être vrai dans les trois cas
Quelle que soit l'option retenue, trois conditions font la différence entre une application que l'entreprise possède et une application qu'elle subit.
Le code est sur votre dépôt. L'organisation GitHub, GitLab ou équivalente appartient à l'entreprise, avec un compte administrateur détenu par la direction ou la DSI. Les développeurs, internes ou externes, y sont invités et peuvent en être retirés. Le jour où quelqu'un part, on révoque un accès, on ne cherche pas le code.
La documentation est reproductible. Un manuel d'exploitation n'est pas un document de vingt pages qui décrit l'architecture. C'est une liste de gestes qu'un développeur étranger au projet peut exécuter sans poser de question : installer l'environnement, lancer les tests, déployer, restaurer une sauvegarde, relancer un service tombé. Le test est simple. Demandez à quelqu'un qui n'a jamais touché l'application de déployer une version en suivant le document. S'il doit appeler l'auteur, la documentation n'est pas reproductible.
Les accès sont nominatifs et révocables. Chaque personne a son propre compte sur chaque service. Les secrets sont dans un coffre partagé dont l'entreprise détient la clé. Aucun compte générique, aucun service ouvert avec une adresse personnelle.
Ces trois conditions ne coûtent presque rien quand le développeur est encore là. Elles coûtent des semaines quand il est parti.
La liste de transfert à faire avant le départ
Si votre développeur est encore en poste, le moment d'agir est maintenant. Présentez la démarche pour ce qu'elle est, une mesure de continuité et non une marque de défiance. La plupart des développeurs sérieux sont soulagés qu'on leur demande enfin de formaliser. La liste ci-dessous est celle que nous utilisons en début de reprise. Elle tient sur une page.
- Inventaire des composants. Applications, bases de données, services tiers, tâches planifiées, avec pour chacun l'hébergeur et le compte propriétaire.
- Transfert des accès. Chaque service passe sous un compte de l'entreprise, les secrets rejoignent un coffre partagé.
- Migration du dépôt. Le code est transféré sur une organisation détenue par l'entreprise, avec l'historique complet. Sur GitHub, c'est une opération de quelques minutes décrite dans la documentation officielle du transfert de dépôt : les tickets, l'historique et les redirections suivent.
- Manuel d'exploitation. Installation, tests, déploiement, sauvegarde, restauration, redémarrage. Rédigé par le développeur, testé par quelqu'un d'autre.
- Carte des dépendances. Versions des langages, bibliothèques et services, avec les fins de support connues.
- Journal des incidents connus. Les problèmes récurrents et la façon dont il les résout. C'est souvent là que se cache le savoir le plus précieux.
- Tests automatisés. Au minimum sur les parcours critiques, pour qu'un repreneur puisse vérifier qu'il n'a rien cassé.
- Session de passation enregistrée. Deux heures où le développeur déploie une version et explique ce qu'il fait devant le futur mainteneur.
Un directeur financier peut piloter cette liste sans compétence technique : il vérifie, point par point, qu'un livrable existe et qu'une seconde personne l'a validé.
Reprendre l'application quand le développeur est déjà parti
Si vous lisez cet article parce que le développeur est déjà parti, la situation est plus inconfortable mais elle se traite. Une reprise d'une application après le départ de son développeur suit une séquence assez stable.
La première étape est de reprendre la main sur ce qui existe : retrouver les accès, parfois via les procédures de récupération des hébergeurs, sauvegarder la base de données et geler toute modification tant qu'on ne comprend pas l'ensemble. C'est exactement par là qu'a commencé la reprise de l'application métier de Fit Doors : un code qui ne démarrait pas, aucun test, des failles ouvertes. L'application a été fiabilisée et mise en ligne sans refonte, et elle est maintenue depuis. Le cas se présente souvent : un site de vente en ligne développé par un prestataire injoignable, qui tourne sur un serveur dont personne n'a le mot de passe. On le récupère sans interruption pour les clients à une condition, ne rien toucher avant d'avoir une copie complète.
Vient ensuite un audit du code et de l'infrastructure pour comprendre l'architecture, mesurer la dette et repérer les versions obsolètes. Cet audit produit le document que vous n'aviez pas et permet de chiffrer la remise à niveau avant de s'engager. C'est la phase d'audit de reprise applicative, celle qui précède tout engagement.
La troisième étape est la stabilisation : supervision en place, tests automatisés sur les parcours critiques, sauvegardes vérifiées, remise à niveau des dépendances planifiée. À partir de là seulement, l'application peut recommencer à évoluer.
Ce chemin vaut aussi pour les applications qui embarquent de l'IA. Un modèle qui tourne sans que personne ne surveille sa dérive, ses coûts d'inférence ou la dépréciation de l'API qu'il utilise est une dépendance de plus, moins visible qu'un développeur mais tout aussi réelle. La maintenance applicative couvre les deux périmètres avec le même principe, et nous avons décrit ce qu'il faut surveiller après la mise en production d'une IA : ce qui tourne chez vous doit rester lisible, supervisé et récupérable par quelqu'un d'autre.
Il n'existe pas de réponse unique entre développeur seul, équipe interne et mainteneur externe. Elle dépend de la criticité de l'application, de son rythme d'évolution et de la taille de l'entreprise. Ce qui ne dépend d'aucun de ces facteurs, c'est l'obligation de pouvoir se passer d'une personne. Une application dont le savoir tient dans une seule tête n'est pas un actif de l'entreprise. C'est un prêt à durée indéterminée, remboursable le jour du départ.
