Tierce maintenance applicative On reprend votre logiciel là où il en est.

La TMA confie à un prestataire extérieur les corrections, les mises à jour, les évolutions et la surveillance d’un logiciel en production. Avant d’accepter le vôtre, nous le lisons et vérifions qu’il vous appartient ; ensuite, tout reste à votre nom.

Faire relire mon logiciel → Les étapes d’une reprise ↓

La passation, puis la veille.

Les accès passent à votre nom, puis la veille commence.

Au démarrage de la reprise, les comptes passent à votre nom et les accès du prestataire sortant sont retirés. Ensuite, la surveillance vérifie en continu que le logiciel fait son travail, pas seulement qu’il répond.

01La remise des accès

Au départ, six accès sont chez le prestataire sortant : chacun peut bloquer la reprise.

Chez le prestataire sortant0

  • Plus rien chez le prestataire sortant.

À votre nom6 / 6

  • Code source Sur le compte du prestataire Sur un compte à votre nom
  • Hébergement Compte du prestataire Compte à votre nom
  • Base de données Sauvegarde jamais restaurée Sauvegarde restaurée une fois
  • Nom de domaine Acheté par le prestataire À votre nom
  • Envoi d’e-mails Clé d’accès du prestataire Clé régénérée à votre nom
  • Documentation Dans la tête du développeur Écrite pendant la reprise

Tout est à votre nom. Mots de passe changés, clés révoquées, invitations supprimées : plus personne d’autre n’entre.

02La veille

Le bâtiment du logiciel repris, en pixel art, la nuit : toutes ses fenêtres sont allumées. OTTO, la mascotte d’OTTOPILOTE, fait sa ronde au pied du bâtiment, une lanterne à la main.
Illustration : le logiciel repris, toutes les lumières allumées, et OTTO qui fait sa ronde.

La surveillance contrôle le résultat attendu, pas seulement la réponse : le parcours principal aboutit, les e-mails arrivent, la sauvegarde se restaure. Ce qu’on surveille ↓

Tout étant déjà à votre nom, partir ne demande qu’une passation. Les étapes d’une reprise ↓

La TMA en clair

Ce que couvre une tierce maintenance applicative, en quatre verbes.

La tierce maintenance applicative (TMA) est la maintenance d’un logiciel assurée par un prestataire extérieur à l’entreprise, qui n’est pas forcément celui qui l’a développé. Pour une PME, elle tient en quatre verbes : corriger, mettre à jour, faire évoluer, surveiller.

Corriger. La maintenance corrective.

Un défaut signalé est reproduit, corrigé, testé, puis mis en production. On note sa cause, pour qu’il ne revienne pas sous une autre forme.

Mettre à jour. La maintenance préventive.

Bibliothèques, langage et hébergement vieillissent même quand personne ne touche au code : on les met à jour avant qu’une faille ou une fin de support ne l’impose.

Faire évoluer. La maintenance évolutive.

Une nouvelle règle, un nouvel écran, une connexion à un autre outil : chaque évolution est chiffrée avant d’être faite.

Surveiller. Le résultat, pas la réponse.

Vérifier en continu que le logiciel fait son travail, pas seulement qu’il répond, et prévenir la bonne personne quand ce n’est pas le cas.

Les situations

Quatre façons d’arriver à une reprise.

Le point de départ change l’ordre des priorités, pas la méthode.

Priorité : les comptes

Votre prestataire arrête son activité

Le temps compte : tant qu’il est joignable, il peut transférer les comptes et expliquer ce qui n’est écrit nulle part. On commence par l’inventaire des accès, avant même de lire le code.

Avant d’accepter.

Six points qu’on vérifie avant de reprendre un logiciel.

Une reprise ne commence pas par le code. Elle commence par savoir si le logiciel vous appartient, s’il est complet et qui en détient les clés. Répondez pour le vôtre : le panneau dit par quoi la reprise commencerait.

  1. Les droits sur le code

    Le contrat signé avec celui qui l’a développé prévoit-il une cession des droits ?

    Sinon Sans cession écrite, les droits restent à celui qui l’a écrit. C’est à régler avant de chiffrer la reprise : avec lui, ou avec un avocat.

  2. Le code source complet

    Tout le code source est-il rassemblé au même endroit, et identique à ce qui tourne en production ?

    Sinon On reconstitue l’écart avant toute modification. Sans code ni production accessible, ce n’est plus une reprise mais une reconstruction, et le devis le dit.

  3. Les comptes

    Hébergement, nom de domaine, base de données, envoi d’e-mails, stores : sont-ils à votre nom ?

    Sinon On les transfère à votre nom en premier, avant de toucher au code. C’est l’inventaire de la passation montrée plus haut, en vrai.

  4. Les sauvegardes

    Une sauvegarde de vos données a-t-elle déjà été restaurée, au moins une fois ?

    Sinon Une sauvegarde est mise en place, puis restaurée une fois, avant la première modification.

  5. Ce qui n’est écrit nulle part

    Réglages du serveur, tâches planifiées, mots de passe, procédures : tout cela est-il documenté ?

    Sinon On l’écrit pendant la reprise, avec vous et, si possible, avec l’ancien prestataire.

  6. Les tests et les bibliothèques

    Le logiciel a-t-il des tests automatiques, et des bibliothèques encore maintenues ?

    Sinon Ce n’est pas un motif de refus : la remise à niveau entre dans le devis, avant les évolutions.

Pourquoi on lit nous-mêmes

Le 28/09/2026, un audit de notre propre site, ottopilote.com, réalisé par un outil d’IA, a remonté 29 points « à arbitrer ». Nous les avons vérifiés un par un dans le code source et en production : 8 étaient faux, 18 partiels, 3 vrais. Un rapport ne remplace pas la lecture : avant une reprise, chaque constat se vérifie dans votre code et sur votre production.

Relevé interne, audit d’ottopilote.com du 28/09/2026
8 faux 18 partiels 3 vrais

Ce que la reprise vous remet

Ce que vous avez en main à la fin de la passation.

Avant la première correction, la reprise produit des pièces que vous gardez, que vous restiez avec nous ou non.

  • Le relevé de lectureLes six points vérifiés, un verdict chacun : ce qui bloque, ce qui se corrige, ce qui peut attendre.
  • Les comptes à votre nomHébergement, domaine, base de données, envoi d’e-mails, stores : chaque compte ouvert ou transféré à votre nom.
  • Les accès du prestataire sortant retirésMots de passe changés, clés révoquées, invitations supprimées : plus personne d’autre n’entre.
  • Un environnement reconstruit depuis le code sourceLa preuve que le code source suffit à faire tourner le logiciel, sans dépendre de l’ordinateur de quelqu’un.
  • Une sauvegarde restauréeRestaurée une fois pour de vrai : une sauvegarde qu’on n’a jamais restaurée ne prouve rien.
  • Ce qui n’était écrit nulle partRéglages du serveur, tâches planifiées, procédures : écrits dans la documentation, à côté du code source.
  • Le code source à votre nomComptes et accès à votre nom ; pour ce que nous écrivons, cession des droits écrite au contrat, code et documentation remis une fois le travail réglé.

La reprise, étape par étape

Comment se passe une reprise chez OTTOPILOTE.

Rien ne change dans le code avant que les comptes soient à votre nom et qu’une sauvegarde ait été restaurée. Nous ne publions pas de durée type : elle dépend de ce que la lecture trouve.

  1. 01Sous 24 h

    Le brief

    Deux ou trois phrases sur le logiciel et sur ce qui ne va plus suffisent. Une réponse humaine sous 24 h ouvrées, avec les premières questions et la liste des accès à prévoir.

  2. 02Avant le devis

    La lecture

    Avec un accès en lecture seule, on lit le code source, la production et la liste des comptes, et on vérifie les six points. Chaque constat se vérifie dans le code et sur la production, pas dans un rapport automatique.

  3. 03Avant de signer

    Le devis

    Gratuit et plafonné. Il sépare la remise à niveau, quand elle est nécessaire, du suivi mensuel. S’il vaut mieux reconstruire que reprendre, il le dit.

  4. 04Au démarrage

    La passation

    Les comptes passent à votre nom, les accès du prestataire sortant sont retirés, l’environnement est reconstruit depuis le code source et une sauvegarde est restaurée. Ensuite seulement, on touche au code.

  5. 05Chaque mois

    Le suivi

    Corrections, mises à jour de sécurité, évolutions chiffrées avant d’être faites, surveillance. Le dépôt du code reste sur un compte à votre nom et la documentation suit chaque changement.

  6. 06À la sortie

    La transmission

    Tout étant déjà à votre nom, partir ne demande qu’une passation : nous formons votre équipe, ou nous transmettons le logiciel proprement, documentation à jour.

Surveillance.

Un logiciel qui répond n’est pas un logiciel qui marche.

Certaines pannes ne produisent aucune erreur : le serveur répond, mais le travail n’est pas fait. La surveillance contrôle donc le résultat attendu, pas seulement la réponse, et chaque alerte a un destinataire nommé.

Ce qu’un contrôle simple voitCe qu’on contrôle en plus
La page d’accueil répond Le parcours principal aboutit : une commande, un devis, une réservation
L’envoi d’un e-mail est accepté Les e-mails partent vraiment, et arrivent
La sauvegarde de la nuit est terminée Elle se restaure
La tâche planifiée a tourné Elle a fait ce qu’elle devait faire
Le document est généré Il est complet, dans sa mise en page
Chez nous aussi

Dans le modèle de proposition commerciale de Cockpit, notre outil de gestion interne. Le 04/09/2026, la page A4 avait une hauteur figée qui coupait ce qui dépassait : mesuré sur une vraie proposition, 285 px de contenu perdus, exclusions comprises. Le 05/09/2026, le document ne chargeait aucune police : « Archivo » retombait sur la police système chez tous les clients, et le devis n’avait jamais été rendu dans sa typographie.

Aucun de ces deux défauts ne produit d’erreur. Pour les voir, il faut regarder le document produit.

Relevé interne, 04 et 05/09/2026 · maquette schématique, pas une capture

Budget

Ce que coûte une TMA, et ce que nous publions.

Nous ne publions pas de prix pour la reprise ni pour le suivi d’un logiciel existant : deux logiciels de même taille peuvent demander des efforts très différents, selon ce que la lecture trouve. Voici ce qui est publié, et ce qui fait varier le devis.

Ce qui est publié

  • Devis gratuit et plafonné, réponse sous 24 hPages de prestation
  • Paiement échelonné par étape livrée, jamais d’acompte aveugleAccueil
  • Suivi mensuel en option, sur devisForfaits
  • Cession écrite au contrat ; code, accès et documentation remis une fois le projet régléForfaits
  • Pour un logiciel que nous avons livré : 30 jours de corrections offertsForfaits

Ce qui fait varier le devis

  1. 01L’état du codeDes tests ou non, des bibliothèques à jour ou non, une documentation ou non.
  2. 02Ce qu’il faut reconstituerUn code source en retard sur la production, des comptes à transférer, un savoir à écrire.
  3. 03Le périmètre du suiviDes corrections seulement, ou des évolutions régulières.
  4. 04La surveillance demandéeCe qui doit être contrôlé, et qui est prévenu.
  5. 05Le délai d’interventionIl se fixe au devis : nous ne publions pas de délai garanti.

Demander un devis →Voir les forfaits →

Pourquoi OTTOPILOTE

Ce qui change quand nous reprenons votre logiciel.

On lit avant de chiffrer.

Pas de devis de reprise sans lecture du code source, de la production et des comptes. Ce qu’on n’a pas pu vérifier est écrit comme tel.

Un devis plafonné.

Le prix est fixé avant de commencer, et le paiement est échelonné par étape livrée, jamais d’acompte aveugle.

Tout reste à votre nom.

Comptes, code source, documentation : à votre nom. Ce que nous écrivons vous est cédé par écrit, une fois réglé.

Des briques qu’une autre équipe peut reprendre.

Ce que nous ajoutons utilise des technologies répandues et documentées : après nous, une autre équipe peut reprendre à son tour.

On dit quand il faut reconstruire.

Si le logiciel ne peut pas être repris dans de bonnes conditions, vous le savez avant de signer.

Une réponse humaine sous 24 h.

Deux ou trois phrases suffisent. Pas de PowerPoint : une lecture honnête et les premières questions.

Questions fréquentes

Ce qu’on nous demande. Avant de signer.

Une autre question ? Écrivez-nous : réponse humaine sous 24 h ouvrées.

Qu’est-ce que la tierce maintenance applicative (TMA) ?

C’est la maintenance d’un logiciel assurée par un prestataire extérieur à l’entreprise, qui n’est pas forcément celui qui l’a développé. Elle couvre les corrections, les mises à jour, les évolutions et la surveillance d’un logiciel déjà en production.

Quelle différence entre TMA et infogérance ?

L’infogérance s’occupe de l’infrastructure : serveurs, réseau, postes de travail. La TMA s’occupe du logiciel lui-même : son code, ses règles, ses évolutions. Une PME a souvent besoin des deux, parfois chez le même prestataire.

Pouvez-vous reprendre un logiciel que vous n’avez pas développé ?

Oui. On commence par vérifier six points : les droits sur le code, le code source complet, les comptes, les sauvegardes, ce qui n’est écrit nulle part et les tests. Le devis, gratuit et plafonné, vient après cette lecture.

Que faire si l’ancien prestataire ne transmet pas le code ?

Relisez d’abord le contrat. En droit français, les droits sur un logiciel créé par un prestataire ne reviennent pas automatiquement au client : la cession doit être écrite (article L131-2 ; l’article L113-9 ne vise que les salariés). Si les droits sont à vous mais pas le code, on repart des comptes à votre nom et de la production ; sans code ni production accessible, c’est une reconstruction, et le devis le dit.

Combien coûte une TMA ?

Nous ne publions pas de prix pour la reprise ni pour le suivi d’un logiciel existant : le montant dépend de l’état du code, de ce qu’il faut reconstituer, du périmètre du suivi et du délai d’intervention demandé. Le devis est gratuit et plafonné, établi après la lecture du code.

Quel délai d’intervention en cas de panne ?

Nous n’en publions pas : il se fixe au devis du suivi mensuel, selon ce que le logiciel exige et ce que la surveillance couvre. Un délai garanti n’a de sens qu’une fois le logiciel connu.

Comment récupérer son logiciel à la fin d’une TMA ?

C’est ce qu’on appelle la réversibilité. Vérifiez trois choses avant de signer : les comptes sont à votre nom, le code source est à votre nom, la documentation est à jour. Chez nous, la cession des droits est écrite au contrat, et code, accès et documentation sont remis une fois le projet réglé : partir ne demande qu’une passation.

Pour aller plus loin

Avant de confier votre logiciel. Trois lectures.

Rédiger le cahier des charges d’un logiciel en neuf chapitres.

Dont les droits sur le code, la réversibilité et la documentation à livrer.

Recette et mise en production d’un logiciel métier.

Vérifier qu’un logiciel fait ce qui était prévu, avant que vos équipes en dépendent.

La dette technique, en clair.

Les raccourcis qui rendent chaque évolution plus lente et plus risquée.

Aussi sur le sujetLe vendor lock-in, ou l’enfermement chez un prestataireCe que surveille un monitoringFaire développer un logiciel métier

Démarrer

Votre logiciel, relu avant d’être repris. Réponse humaine sous 24 h ouvrées.

Deux ou trois phrases sur le logiciel et sur ce qui ne va plus suffisent. Devis gratuit et plafonné, après la lecture.

Faire relire mon logiciel → Voir les forfaits