Garder la maîtrise de son prestataire de développement

Quand on me demande de reprendre une application dont le prestataire ne répond plus, la crise elle-même n’est presque jamais le vrai problème. Le vrai problème a commencé des années plus tôt, le jour où le nom de domaine a été déposé sur le compte de l’agence « pour aller plus vite », où le dépôt de code a été créé dans son organisation GitHub, et où personne côté client n’a demandé à voir la procédure de déploiement. Rien de tout cela n’était de la mauvaise foi. C’était simplement plus pratique, et personne n’est revenu dessus.

J’ai décrit dans un autre article ce qu’il faut faire quand le prestataire est déjà injoignable : sécuriser le domaine, copier la production, reconstruire un environnement. Celui-ci traite de l’étape d’avant, celle qui coûte beaucoup moins cher : comment garder la maîtrise d’un prestataire qui fonctionne bien aujourd’hui, pour que son départ, son rachat ou sa défaillance restent demain un simple changement de fournisseur. J’ai passé douze ans de l’autre côté de la table, à diriger une société de développement dont les clients confiaient leur code à nos équipes ; les règles ci-dessous sont celles que j’aurais aimé voir appliquer par tous nos clients, et que les meilleurs appliquaient.

1. Le principe : l’entreprise possède, le prestataire est invité

Tout le reste découle d’une règle simple. Chaque actif technique (domaine, hébergement, dépôt de code, comptes de services tiers, sauvegardes) est ouvert au nom de l’entreprise, payé par l’entreprise, et le prestataire y reçoit des accès nominatifs qu’on peut lui retirer. Jamais l’inverse.

Cette règle a une conséquence pratique qu’on oublie : il faut un propriétaire interne. Pas forcément un technicien. Un DSI, un directeur administratif, un dirigeant, peu importe, mais une personne identifiée qui détient les accès administrateur, reçoit les factures et les alertes d’expiration, et sait où se trouve le coffre-fort des mots de passe. Sur les reprises que j’ai menées, le premier point bloquant est presque toujours là : les comptes existent, parfois même au nom de la société, mais l’adresse e-mail rattachée est celle d’un salarié parti ou d’un chef de projet de l’agence.

Deux réglages évitent l’essentiel de ces situations :

• Une adresse générique interne (du type tech@votre-entreprise.fr) comme identifiant propriétaire de tous les comptes, redirigée vers au moins deux personnes de l’entreprise.
• Un coffre-fort de mots de passe d’entreprise, avec un espace partagé pour le prestataire : il y dépose les secrets qu’il crée, vous gardez la main sur le coffre.

2. Le code source et les dépôts

Le code doit vivre dans une organisation GitHub, GitLab ou Bitbucket créée et détenue par l’entreprise. Les développeurs du prestataire y sont invités comme membres ou collaborateurs externes. Si le dépôt est aujourd’hui dans l’organisation du prestataire, la plateforme permet de le transférer sans perdre l’historique ; c’est une opération de quelques minutes, à faire pendant que la relation est bonne.

Ce que je vérifie :

• Le rôle propriétaire (owner) est détenu par au moins deux comptes de l’entreprise, avec double authentification. Le prestataire a des droits d’écriture, pas d’administration de l’organisation.
• La branche principale est protégée : pas de poussée directe, fusion par demande de revue (pull request ou merge request). Cela crée une trace de chaque changement, et une occasion de le relire.
• La production correspond au dépôt. Le déploiement part du dépôt, par un pipeline, et non d’un poste de développeur ou d’une modification faite à la main sur le serveur. Un dépôt complet mais dépassé par la production ne vaut presque rien en cas de reprise.
• Il n’y a pas de dépôt fantôme. Je demande la liste de tous les dépôts utilisés : application, scripts d’infrastructure, applications mobiles, bibliothèques internes, thème graphique. Il en manque souvent un, hébergé ailleurs, dont dépend le build.
• Les dépendances privées sont accessibles. Un paquet Composer ou npm hébergé sur le registre privé du prestataire est une dépendance cachée : le jour où l’accès est coupé, l’application ne se construit plus.

Enfin, je fais faire un miroir automatique du dépôt vers un second emplacement de l’entreprise (une autre plateforme ou un stockage de sauvegarde). Ce n’est pas de la méfiance : cela protège aussi d’une erreur de manipulation ou d’un compte compromis.

3. Hébergement, domaine et services tiers au nom de l’entreprise

Le nom de domaine est l’actif le plus critique et le plus souvent mal rattaché. Il doit être déposé chez un registrar sur un compte de l’entreprise, avec l’entreprise comme titulaire, le renouvellement automatique activé et un moyen de paiement de l’entreprise. Le prestataire peut avoir un accès délégué à la zone DNS s’il en a besoin, mais pas au compte qui détient le domaine.

Même logique pour l’hébergement : le compte cloud ou le contrat d’hébergement est souscrit par l’entreprise, qui en reçoit les factures. Le prestataire y travaille avec des comptes nominatifs ou des rôles délégués, révocables. Un hébergement « inclus dans la maintenance » et refacturé est confortable, mais c’est exactement le montage qui permet à un serveur de s’éteindre le jour où le prestataire cesse de payer son propre fournisseur. Si ce montage est conservé pour des raisons commerciales, il faut au minimum un accès administrateur de l’entreprise et une clause de transfert du contrat.

Puis viennent tous les services dont l’application dépend, et que personne ne liste spontanément. Je tiens un registre simple, mis à jour à chaque nouveau service :

Les stores mobiles méritent une attention particulière : une application publiée sous le compte du prestataire ne se transfère pas toujours simplement. C’est à régler avant la première publication.

4. Documentation et environnements reproductibles

Posséder le code ne suffit pas si personne d’autre que le prestataire ne sait le faire tourner. La documentation que je demande n’est pas un dossier de conception de deux cents pages, que personne ne tient à jour. C’est un socle court, vivant dans le dépôt, qui répond à quatre questions :

1. Comment installer le projet sur un poste neuf : un README qui mène à une application qui démarre, idéalement avec un environnement conteneurisé (Docker Compose ou équivalent) qui fixe les versions du langage, de la base et des services.
2. Comment déployer : le pipeline, les environnements (recette, production), la procédure de retour arrière.
3. Comment c’est construit : un schéma d’architecture d’une page, la liste des services tiers, les tâches planifiées, et un registre des décisions d’architecture (ADR) qui explique pourquoi les choix structurants ont été faits.
4. Comment restaurer : où sont les sauvegardes, comment les restaurer, et la date du dernier test réussi.

Le test qui tranche est simple, et je le fais faire au moins une fois par an : une personne extérieure au prestataire (un développeur interne, un auditeur, un autre prestataire) installe le projet en suivant uniquement la documentation. Le temps qu’elle y passe et les questions qu’elle doit poser mesurent votre dépendance réelle. Si l’installation est impossible sans appeler le prestataire, la documentation est à reprendre, et c’est un livrable à exiger comme un autre.

Même exigence pour la restauration : une sauvegarde jamais restaurée est une hypothèse. Je fais inscrire au contrat un test de restauration périodique, avec un compte rendu daté, sur un environnement distinct de la production.

5. Les clauses à vérifier dans le contrat

Je ne rédige pas les contrats, c’est le travail d’un avocat. Mais je relis toujours la partie technique, parce que c’est là que se cachent les clauses qui coûtent cher le jour du départ. Les points que je vérifie :

• La cession des droits sur le code. En droit français, le simple fait de payer un développement ne transfère pas automatiquement les droits d’auteur sur le logiciel. Le contrat doit prévoir une cession explicite des droits patrimoniaux sur les développements spécifiques, avec l’étendue, la durée et le territoire. Si le prestataire sous-traite à des freelances, il doit lui-même avoir obtenu leurs droits pour pouvoir vous les céder.
• Les composants du prestataire. Beaucoup d’agences réutilisent un socle maison (un framework interne, un module de back-office). Il est normal qu’elles en gardent la propriété, mais il vous faut alors une licence d’utilisation perpétuelle, transférable à un repreneur, et l’accès au code source de ce socle.
• La réversibilité. Une clause qui décrit précisément ce qui est remis en fin de contrat (code, données, documentation, accès, configuration, secrets), dans quel délai, sous quel format, et l’assistance prévue pendant la transition (un nombre de jours de transfert de connaissance avec la nouvelle équipe). Une clause qui dit seulement « le prestataire assurera la réversibilité » ne protège presque rien.
• Le préavis et la continuité. Le prestataire doit continuer à assurer la maintenance corrective pendant la période de transition, même en cas de désaccord commercial. Sinon, la négociation se fait avec une production en otage.
• La sous-traitance. Savoir qui écrit réellement le code, et dans quel pays, a des conséquences sur les droits, sur la confidentialité et sur le traitement des données personnelles (le prestataire est généralement sous-traitant au sens du RGPD, ce qui impose un accord de traitement des données).

Si le contrat actuel ne prévoit rien de tout cela, ce n’est pas une raison pour le dénoncer. C’est une raison pour négocier un avenant pendant que la relation est bonne. Un prestataire sérieux accepte en général sans difficulté ; celui qui résiste fortement à la réversibilité vous donne une information.

6. Les indicateurs de pilotage

On ne pilote pas un prestataire au ressenti ni au seul respect du budget. Je suis un petit nombre d’indicateurs, tirés autant que possible des outils eux-mêmes (dépôt, outil de tickets, supervision) plutôt que de déclarations, et revus en comité mensuel :

Aucun de ces chiffres n’a de valeur cible universelle. Ce qui compte, c’est leur tendance sur plusieurs mois, et les explications qui accompagnent un changement brusque. J’ajoute toujours une question qualitative à chaque comité : « qu’est-ce qui vous ralentit en ce moment dans ce code ? ». La réponse est souvent la première description honnête de la dette technique.

7. Les signaux faibles d’une dérive

Les relations qui finissent mal donnent presque toujours des signaux des mois avant la rupture. Isolément, chacun s’explique ; c’est leur accumulation qui doit alerter :

• La rotation silencieuse de l’équipe. Les noms changent dans l’historique des commits sans annonce, le développeur historique n’apparaît plus, les nouveaux posent des questions déjà tranchées.
• Les commits se raréfient alors que les factures restent stables. L’historique du dépôt est la mesure la plus objective de l’activité réelle ; il se lit en une commande.
• Les correctifs faits en direct. Une correction urgente appliquée sur le serveur « qu’on remettra dans le dépôt plus tard ». Une fois, c’est un incident. Régulièrement, c’est une production qui diverge du code.
• Les estimations qui s’allongent sur des demandes simples. Souvent le signe d’une dette technique qui grossit, ou d’une équipe qui ne connaît plus bien le code.
• Les réponses vagues sur les accès. « On vous enverra ça » à une demande d’accès administrateur, de documentation ou de procédure de restauration, plusieurs fois de suite.
• Les mises à jour toujours repoussées. La version du langage ou du framework approche de sa fin de support et la montée de version n’est jamais prioritaire.
• Des services ajoutés sans vous. Une nouvelle clé d’API, un nouveau service tiers, un sous-domaine qui apparaît sans avoir été discuté.
• La dépendance au chef de projet. Une seule personne chez le prestataire sait répondre, et ses absences bloquent tout.

Quand plusieurs de ces signaux apparaissent, je ne recommande pas de changer de prestataire. Je recommande un audit court, en lecture seule, qui mesure l’état réel du code, des accès et de la documentation. Soit il rassure, soit il donne une base factuelle pour discuter, et éventuellement pour préparer une transition dans de bonnes conditions. La méthode est proche de celle d’une due diligence technique, appliquée à votre propre application.

8. La revue annuelle de réversibilité

Pour que tout cela ne reste pas théorique, je propose une revue d’une demi-journée par an, avec le prestataire, sur une liste fixe. Elle sert aussi de preuve lors d’une levée de fonds ou d’une cession.

• Le domaine est au nom de l’entreprise, renouvellement automatique actif, expiration à plus de six mois.
• Les comptes d’hébergement et de services tiers figurant au registre sont tous au nom de l’entreprise, et le registre est à jour.
• Au moins deux personnes de l’entreprise ont un accès propriétaire à l’organisation de code, avec double authentification.
• La production a été déployée depuis le dépôt lors de la dernière mise en production, et rien n’a été modifié à la main depuis.
• Un tiers a installé le projet à partir de la documentation dans l’année.
• Une restauration complète a été testée dans l’année, avec un compte rendu daté.
• La liste des accès du prestataire est revue, et les comptes des personnes parties sont supprimés.
• Les secrets sont dans le coffre-fort de l’entreprise, et leur rotation est possible sans le prestataire.
• La clause de réversibilité et la cession de droits couvrent bien les développements de l’année.

Si un point échoue, il devient un ticket prioritaire, avec une date. C’est tout. Pas de procès d’intention, juste une liste qui se ferme.

Un prestataire qu’on peut remplacer facilement est un prestataire avec qui on travaille bien plus sereinement.

Les leçons

• L’entreprise possède, le prestataire est invité. Domaine, hébergement, dépôts et services tiers ouverts et payés par l’entreprise, accès nominatifs et révocables pour le prestataire.
• Un propriétaire interne identifié. Une adresse générique, deux personnes, un coffre-fort de mots de passe d’entreprise.
• Le dépôt fait foi parce que la production en sort. Déploiement par pipeline, branche protégée, pas de correctif en direct.
• La documentation se teste. Un tiers installe le projet seul, une restauration est faite chaque année.
• Le contrat se relit côté technique. Cession explicite des droits, licence sur les composants du prestataire, réversibilité détaillée, continuité pendant la transition.
• Peu d’indicateurs, lus dans les outils. Leur tendance compte plus que leur valeur.
• Les signaux faibles déclenchent un audit, pas une rupture. On décide sur des faits.