Externaliser sa maintenance applicative : critères, risques et étapes

Externaliser sa maintenance applicative, c’est confier à un prestataire les corrections, les mises à jour et les évolutions d’une application, tout en gardant la décision. L’opération réussit sur trois points : un périmètre écrit, des engagements qui se mesurent et une sortie prévue dès la signature. Ce guide passe en revue ce que recouvre l’externalisation, quand elle se justifie, ses risques et la façon de la mener.

Il s’adresse aux dirigeants, aux DSI et aux responsables de produit qui ont une application en service et se demandent qui doit l’entretenir. La maintenance applicative, souvent appelée TMA, n’est pas une assurance contre les pannes : c’est une organisation, avec ses règles.

Ce que recouvre l’externalisation de la maintenance applicative

On parle de « tierce maintenance applicative » (TMA) quand un tiers entretient une application qu’il n’a pas forcément écrite. Le cahier des clauses administratives générales des marchés publics de techniques de l’information et de la communication, le CCAG-TIC 2021, en donne une définition utile bien au-delà des marchés publics : la TMA regroupe les prestations qui conservent un système d’information dans un état lui permettant de remplir sa fonction, et elle peut aussi porter sur l’évolution ou l’adaptation des logiciels.

Le même article distingue quatre familles de travaux. Ce sont elles qui structurent un périmètre de maintenance.

Source : CCAG-TIC 2021, article 38 (arrêté du 30 mars 2021). Les exemples sont les nôtres.

Ce que la maintenance applicative ne comprend pas d’office, c’est l’exploitation. Le même texte définit l’infogérance comme l’externalisation de la gestion ou de l’exploitation de tout ou partie du système informatique, et précise qu’elle peut porter sur de la tierce maintenance applicative ou sur l’hébergement des infrastructures. Un même contrat peut combiner les deux, mais ce sont deux périmètres : qui héberge, qui supervise, qui sauvegarde et qui restaure doit être écrit.

Quand externaliser, et quand garder en interne

L’externalisation n’est pas une réponse à tout. Elle se justifie dans des situations assez reconnaissables.

• L’application est en service et stable, mais l’équipe qui l’a construite est mobilisée sur de nouveaux projets.
• Sa pile technique demande des compétences que l’entreprise n’a pas vocation à recruter.
• La charge de maintenance est irrégulière : trop faible pour un poste à temps plein, trop forte par à-coups pour être absorbée.
• Les mises à jour de sécurité prennent du retard, faute de disponibilité.
• L’entreprise veut un cadre : des demandes suivies, des engagements écrits, un interlocuteur.

À l’inverse, mieux vaut garder la maintenance en interne dans trois cas.

• L’application est le cœur du produit et change chaque semaine : la maintenance ne se sépare pas du développement.
• La connaissance métier n’est écrite nulle part et ne tient qu’à l’équipe en place : il faut d’abord la documenter.
• L’entreprise dispose déjà d’une équipe dimensionnée pour cela, avec une documentation à jour.

Entre les deux, une formule mixte existe : l’équipe interne garde la feuille de route et les évolutions structurantes, le prestataire prend le préventif, le correctif et l’adaptatif.

Ce que l’on n’externalise jamais

Externaliser l’exécution ne veut pas dire déléguer la décision. Quatre choses restent dans l’entreprise, quel que soit le prestataire.

• Les priorités. Ce qui est corrigé d’abord, ce qui attend, ce qui ne sera pas fait : c’est un arbitrage métier.
• La propriété du code. Avec un prestataire externe, elle suppose une cession de droits écrite : payer un développement ne suffit pas à en détenir les droits, rappelle Bpifrance Création.
• Les comptes et les accès. Dépôt de code, hébergement, nom de domaine, services tiers : ils sont au nom de l’entreprise, le prestataire y est invité.
• La connaissance métier. Un référent interne qui sait ce que l’application doit faire, et pourquoi.

Les trois risques, et comment les couvrir

Un quatrième point n’est pas un risque mais une obligation. Si l’application traite des données personnelles, le prestataire agit comme sous-traitant au sens du RGPD. L’article 28 du RGPD impose un contrat écrit. Il prévoit notamment que le sous-traitant ne traite les données que sur instruction documentée, qu’il en assure la confidentialité et la sécurité, qu’il ne fait appel à un autre sous-traitant qu’avec une autorisation écrite, et qu’il supprime ou renvoie les données à la fin de la prestation.

Choisir le prestataire : ce qu’il faut regarder

Les présentations commerciales se ressemblent. Les réponses à ces six points, elles, diffèrent.

• L’expérience sur votre pile technique. Qui interviendra réellement, et sur quelles applications comparables ?
• La phase d’entrée. Commence-t-il par un audit de l’existant, et que contient le document remis ?
• L’outillage. Suivi des demandes, déploiement automatisé, supervision : ce qu’il apporte, et ce qui restera chez vous à la fin du contrat.
• La transparence du suivi. Voyez-vous les demandes, leur état et le temps passé sans avoir à le demander ?
• La continuité. Plusieurs personnes connaissent-elles votre application, et qu’est-il prévu pour les congés et les absences ?
• La langue et les horaires. Prestataire proche ou partenaire nearshore francophone : ce qui compte, ce sont des horaires de travail communs et des échanges dans votre langue.

Les étapes d’une externalisation

• Cadrer. Lister les applications concernées, leur criticité, ce qui est attendu et ce qui reste en interne.
• Faire auditer l’existant. Le prestataire lit le code, l’installe, examine les versions, les tests, le déploiement et les sauvegardes avant de s’engager.
• Organiser la transition. Transfert des accès, passation avec l’équipe en place, premières interventions accompagnées.
• Entrer en régime courant. Des demandes suivies, des mises à jour planifiées, des comptes rendus réguliers : c’est le fonctionnement normal d’une maintenance applicative (TMA).
• Piloter. Un point périodique sur les demandes, les incidents, l’état de l’application et les priorités à venir.

La transition mérite un calendrier écrit. À titre de repère, le CCAG-TIC 2021 prévoit, pour les marchés publics d’infogérance, une période de transition d’une durée maximale de six mois : c’est la phase pendant laquelle la responsabilité technique passe au nouveau prestataire. Un contrat privé fixe librement la sienne, mais il gagne à la borner.

Le contrat : trois clauses à ne pas négliger

• Le périmètre. Les applications couvertes, les familles de travaux incluses, ce qui relève de l’exploitation, et ce qui se chiffre à part.
• Les niveaux de service. Pour l’infogérance, le CCAG-TIC 2021 demande que les documents du marché définissent les niveaux de service attendus, les moyens de les mesurer et les sanctions en cas de non-respect. La logique vaut pour un contrat privé : un engagement qui ne se mesure pas ne s’applique pas.
• La réversibilité. L’article 42 du même texte distingue la réversibilité (le client reprend les prestations, ou les confie à un tiers qu’il désigne) et la transférabilité (un nouveau prestataire les reprend), décrites dans un plan. Prévoyez ce plan dès la signature : ce qui vous est remis, dans quels formats, avec quelle assistance.

Ces trois clauses ne sont pas les seules. Notre guide du contrat de maintenance applicative passe en revue les neuf clauses à vérifier avant de signer, de la rémunération à la propriété du code.

Questions fréquentes

Externaliser sa maintenance applicative : commencez par le périmètre

Une externalisation de la maintenance applicative tient sur peu de choses : savoir ce que l’on confie, garder ce qui ne se délègue pas, mesurer ce qui est promis et prévoir la sortie. Le reste, outils et organisation, en découle.

Pour aller plus loin, l’équipe iones réalise l’audit et la maintenance applicative d’applications existantes. Vous pouvez aussi nous écrire pour un premier échange.