Votre prestataire ne répond plus, personne en interne ne sait comment tourne l'outil, et une panne bloque déjà une équipe. Signer une TMA dans cet état, c'est acheter une maison sans visiter la cave. L'audit de reprise applicative sert à descendre dans la cave avant de s'engager, pour que le prestataire écrive des engagements qu'il pourra tenir. Le scénario qui suit reprend une situation que nous rencontrons souvent dans les PME de services. Il montre pourquoi le contrat ne peut être rédigé qu'à la fin de cette phase.
Le point de départ : un logiciel métier, un éditeur injoignable, aucun accès au code
L'entreprise compte une centaine de salariés, répartis sur quatre agences régionales. Son activité repose sur un outil de planification et de facturation développé sur mesure en 2017 par une petite société de développement. Cet outil gère les plannings des techniciens, les bons d'intervention, les devis et la facturation. Chaque jour, une quarantaine de personnes s'y connectent.
Début 2025, l'éditeur ne répond plus. Le dernier échange par courriel date de six mois. La ligne téléphonique sonne dans le vide. Le site de la société affiche toujours une page d'accueil, mais l'immatriculation indique une procédure de liquidation.
Ce que le dirigeant avait sous la main : un accès à l'application en tant qu'administrateur, une facture annuelle d'hébergement payée à un intermédiaire, et un vieux fichier Word décrivant les fonctionnalités. Ce qu'il n'avait pas : le code source, les accès au serveur, les identifiants de la base de données, le nom de domaine technique utilisé par l'API mobile, ni la moindre idée de l'endroit où tournait l'application.
L'inquiétude était concrète. Deux semaines avant notre premier échange, le module d'export comptable avait cessé de fonctionner. L'assistante de direction ressaisissait les factures à la main dans le logiciel comptable. Personne ne savait pourquoi l'export était tombé, ni combien de temps la ressaisie allait durer.
Ce que le dirigeant demandait, et pourquoi la réponse ne pouvait pas être un devis
La demande initiale tenait en une phrase : « Reprenez la maintenance de l'outil, dites-moi combien ça coûte par mois et à quelle vitesse vous intervenez quand ça casse. »
La demande est légitime, et notre offre y répond par un audit de reprise facturé puis run sous engagement. Mais y répondre le premier jour aurait été malhonnête. Un prestataire qui annonce un forfait mensuel et des délais d'intervention sans avoir lu une ligne de code ne s'engage sur rien : il parie. Et quand le pari est perdu, c'est le client qui paie, soit par un avenant, soit par une équipe qui tourne au ralenti pendant que le prestataire découvre le sujet en production.
Nous avons donc proposé autre chose. Une phase courte, facturée, avec un livrable précis : une cartographie du système, la liste des risques, et un périmètre sur lequel nous pouvions écrire des engagements. Le dirigeant a accepté, en précisant qu'il n'était pas certain de signer la suite. Cette liberté fait partie de l'accord : l'audit doit avoir une valeur en soi.
Les cinq points lus par l'audit
La première semaine a été consacrée à retrouver les accès. C'est souvent l'étape la plus longue et la moins technique. Le prestataire d'hébergement, un revendeur régional, a fini par fournir un accès au serveur après vérification de l'identité du dirigeant et présentation des factures. Le code source n'était dans aucun dépôt Git : il a été récupéré directement sur le serveur de production, sans historique de versions. Le compte administrateur de la base de données utilisait le mot de passe par défaut de l'installation.
Une fois entrés, nous avons lu cinq choses, dans cet ordre.
Le code. Environ soixante mille lignes de PHP, sur une version du langage qui ne reçoit plus de correctifs de sécurité depuis fin 2022. Une partie du code était structurée proprement, une autre avait visiblement été écrite dans l'urgence, avec des requêtes SQL construites par concaténation de chaînes. Aucun test automatisé.
L'infrastructure. Un serveur virtuel unique hébergeant l'application, la base de données et les fichiers. Pas de séparation entre environnement de test et de production.
Les dépendances. Une trentaine de bibliothèques tierces, dont une moitié n'avait pas été mise à jour depuis l'installation. Deux d'entre elles n'existent plus chez leur mainteneur d'origine. Le générateur de PDF utilisé pour les devis en faisait partie.
Les flux de données. L'application échangeait avec trois systèmes extérieurs : le logiciel comptable, une application mobile pour les techniciens, et un service d'envoi de SMS. Ces trois flux n'étaient documentés nulle part. Nous les avons reconstitués en lisant les journaux du serveur et le code, puis en interrogeant les utilisateurs.
Les sauvegardes. Une tâche planifiée copiait la base de données chaque nuit sur le même disque que la production. Personne n'avait jamais tenté de restaurer une de ces copies.
Les constats qui ont changé le contrat
Le rapport a listé une vingtaine de constats. Cinq d'entre eux changeaient la nature du contrat à écrire.
Premier point de rupture : l'export comptable. La panne qui avait déclenché l'appel venait d'une mise à jour côté logiciel comptable, qui avait modifié le format d'import. Le connecteur, écrit en dur, n'avait aucune tolérance au changement. Correction rapide, mais le même incident se reproduira à chaque évolution du logiciel comptable si le connecteur n'est pas réécrit.
Deuxième point de rupture : le générateur de PDF. La bibliothèque abandonnée fonctionnait encore, mais uniquement sur la version actuelle du langage. Toute mise à niveau du serveur, pourtant indispensable pour la sécurité, casserait la production des devis. Il fallait donc planifier le remplacement avant la mise à niveau, pas après.
Troisième point de rupture : l'application mobile. Elle communiquait avec un sous-domaine dont le nom de domaine expirait trois mois plus tard, et dont le titulaire était l'éditeur disparu. Sans action, les techniciens perdaient leur outil de terrain à une date connue.
La faille. Les requêtes construites par concaténation permettaient, depuis le formulaire de recherche des clients, de lire n'importe quelle table de la base. Un utilisateur authentifié, ou quelqu'un ayant récupéré un mot de passe, pouvait extraire l'ensemble du fichier client. Nous l'avons vérifié sur une copie, jamais sur la production.
La base sans sauvegarde testée. Nous avons tenté une restauration de la copie nocturne sur un serveur de test. Elle a échoué : la copie était tronquée depuis plusieurs mois, faute d'espace disque. En cas de panne du serveur, l'entreprise aurait perdu son historique de facturation. Ce point a été corrigé pendant l'audit, sans attendre la remise du rapport.
Comment les constats sont devenus un périmètre et des engagements écrits
À ce stade, nous savions ce que nous reprenions. C'est seulement à partir de là que les engagements du contrat ont pu être rédigés, parce qu'un engagement n'a de sens que sur un système dont on connaît les modes de défaillance.
Le contrat a été construit en trois couches.
La première couche est la remise à niveau. Elle a été planifiée sur plusieurs mois et ordonnée en fonction des dépendances entre les chantiers : sécuriser le domaine de l'application mobile, remplacer le générateur de PDF, corriger la faille, puis migrer le langage et le serveur, et enfin réécrire le connecteur comptable. Chaque étape a une date, un critère de validation et un responsable côté client.
La deuxième couche est la supervision et le maintien en condition opérationnelle. Elle inclut la surveillance du serveur et des flux, la détection des erreurs avant que les utilisateurs ne les signalent, les sauvegardes externalisées avec un test de restauration régulier, et les mises à jour de sécurité. Les délais de prise en charge et de rétablissement ont été écrits par catégorie d'incident, sur la base de ce que l'audit avait révélé, et définis au contrat. Ils sont différents pour une facturation bloquée et pour un libellé mal aligné.
La troisième couche est la réversibilité. Le code a été placé dans un dépôt appartenant à l'entreprise. Les accès au serveur, à la base et au domaine sont au nom du dirigeant, avec un gestionnaire de mots de passe dont il détient la clé. La documentation produite pendant l'audit fait partie des livrables du contrat et est mise à jour à chaque intervention. Si l'entreprise change de prestataire demain, elle repart avec tout. C'est la première des exigences à poser à un prestataire de maintenance, et la raison pour laquelle une application non maintenue coûte si cher le jour où l'on veut en reprendre le contrôle.
Le prix a été fixé à la fin, pas au début. Il repose sur un volume d'intervention estimé à partir de l'audit, révisable après six mois sur la base du rapport d'activité mensuel. Ce rapport liste les incidents, leur cause, le temps passé et ce qui a été fait pour qu'ils ne reviennent pas.
Ce qui a été refusé et pourquoi : le système embarqué hors périmètre
L'audit a aussi servi à dire non. Les techniciens utilisaient, en plus de l'application mobile, un boîtier de géolocalisation installé dans les véhicules. Ce boîtier remontait des positions vers un serveur tiers, dont l'application métier lisait les données. Le dirigeant souhaitait que la maintenance couvre l'ensemble, boîtiers compris.
Nous avons refusé cette partie du périmètre, pour deux raisons. Le micrologiciel des boîtiers appartient à leur fabricant, qui ne fournit ni code ni documentation. Et le serveur intermédiaire est opéré par une société que nous ne pouvons pas engager contractuellement. Prendre un engagement de rétablissement sur un composant que nous ne pouvons ni lire ni modifier reviendrait à vendre une garantie sans en avoir les moyens.
Ce que nous avons proposé à la place : surveiller le flux entrant côté application, alerter en cas d'interruption, et documenter la procédure de bascule manuelle. Le boîtier lui-même reste sous la responsabilité de son fabricant, avec un contrat distinct que le dirigeant a renégocié dans la foulée.
Comment classer les constats : critique, important, optimisation
Une vingtaine de constats ne se traitent pas tous le même jour. Pour les ordonner, nous posons deux questions sur chacun : quel impact sur l'activité (facturation bloquée, risque juridique, outil de terrain qui s'arrête) et quel effort pour le corriger. On commence par ce qui pèse lourd et coûte peu.
- Critique : à corriger tout de suite, comme la faille qui expose le fichier client ou la sauvegarde inutilisable.
- Important : à planifier dans le trimestre, comme le remplacement d'une bibliothèque abandonnée avant la montée de version du serveur.
- Optimisation : à envisager plus tard, comme la séparation des environnements de test et de production.
Les signes qui montrent qu'un logiciel accumule de la dette
Avant même l'audit, le terrain donne des indices. Une évolution qui prenait quelques jours en demande désormais plusieurs semaines, parce que personne n'ose toucher à un code devenu fragile. Des anciens bugs corrigés réapparaissent après une modification voisine. Un nouveau développeur met des mois à comprendre le système avant d'être utile. Si vous en reconnaissez deux ou trois, la reprise doit passer par un audit avant tout engagement de maintenance.
Les livrables que le client garde, même sans signer
Le dirigeant a signé. S'il ne l'avait pas fait, il serait reparti avec trois livrables.
Ce sont eux qui justifient que l'audit soit facturé et non offert. D'abord une cartographie complète du système : composants, flux, accès, dépendances, avec les noms des comptes et les emplacements réels. C'est le document que l'éditeur disparu n'avait jamais produit. Ensuite un plan de remédiation ordonné, avec pour chaque risque une action, un effort estimé et une échéance. Enfin les accès récupérés et sécurisés, dont le code source déposé dans un espace appartenant à l'entreprise.
Avec ces trois éléments, l'entreprise pouvait consulter d'autres prestataires sur une base saine, ou confier le plan à un développeur indépendant. Elle n'était plus dépendante de la personne qui avait fait l'audit. C'est le critère pour juger un audit de reprise : après sa livraison, le client doit être plus libre qu'avant, pas moins.
Cette liberté a aussi un effet sur la qualité du contrat qui suit. Un client qui peut partir négocie un contrat qu'il comprend. Cette question rejoint celle du changement de prestataire de maintenance applicative : la difficulté n'est presque jamais technique, elle tient à ce que le client ne possède pas.
Ce que l'audit de reprise n'est pas : un audit de dette technique complet
L'audit de reprise répond à une question précise : qu'est-ce que nous reprenons, et à quelles conditions pouvons-nous nous engager dessus ? Il ne cherche pas à évaluer la qualité globale du code, à mesurer la dette accumulée ou à chiffrer une refonte. Il s'arrête là où l'engagement contractuel commence.
Un audit de dette technique va plus loin et plus large. Il sert à décider s'il faut refondre, réécrire ou moderniser progressivement, et dans quel ordre, selon la grille d'arbitrage entre remise à niveau et refonte. Dans le cas décrit ici, cette question s'est posée six mois après le début du contrat, une fois la production stabilisée. Elle a fait l'objet d'un travail distinct, avec d'autres méthodes et un autre livrable.
L'audit de reprise est la première étape de notre offre de reprise de maintenance applicative. Il s'applique de la même manière à un logiciel métier classique et à un système embarquant des modèles d'IA, avec dans ce second cas des points de lecture supplémentaires : coûts d'inférence, dérive des modèles, dépendance à un fournisseur d'API, autant de points détaillés dans notre guide sur ce qu'il faut surveiller après la mise en production d'une IA. Dans tous les cas, la règle reste la même. On lit d'abord, on s'engage ensuite.
