TMA au forfait ou en régie : comment choisir le bon modèle

Au moment de confier la maintenance d’une application, la question du prix en cache une autre : à quoi le prestataire s’engage-t-il ? Au forfait, il s’engage sur un périmètre et des niveaux de service ; en régie, sur des compétences et du temps ; aux unités d’œuvre, sur un barème par type de demande. Aucun de ces modèles n’est meilleur en soi. Ce guide explique ce que chacun engage, à quels travaux il convient, et comment les combiner dans un même contrat.

Il s’adresse aux dirigeants, aux DSI et aux acheteurs qui préparent ou renégocient un contrat de maintenance applicative (TMA, tierce maintenance applicative). Vous n’y trouverez ni tarif journalier ni pourcentage « habituel » : ils dépendent de l’application et se négocient. Vous y trouverez de quoi choisir le modèle avant de comparer les prix.

Forfait, régie, unités d’œuvre : de quoi parle-t-on

Les mots varient d’un prestataire à l’autre, mais une TMA se paie de trois façons. Ce qui les distingue n’est pas le montant : c’est ce que le prestataire s’engage à livrer, et qui supporte le risque quand le volume de travail change.

Le droit des marchés publics ne connaît que deux formes de prix, et la distinction éclaire aussi les contrats privés. Selon l’article R2112-6 du code de la commande publique, les prix sont soit « des prix unitaires appliqués aux quantités réellement livrées ou exécutées », soit « des prix forfaitaires appliqués à tout ou partie du marché, quelles que soient les quantités livrées ou exécutées ». Rapportées à ce texte, la régie et les unités d’œuvre sont des prix unitaires : on paie ce qui a été fait. Le forfait relève de la seconde famille. Et les mots « tout ou partie » permettent qu’un forfait ne couvre qu’une partie d’un marché, le reste étant payé à prix unitaires.

Le forfait : prévisible, si le périmètre est connu

Au forfait, vous payez un montant fixe par mois ou par an, et le prestataire prend en charge un périmètre décrit au contrat : les applications et les environnements couverts, les familles de travaux incluses, les niveaux de service. Que le mois compte trois anomalies ou trente, la facture ne change pas. C’est le modèle qui donne la meilleure visibilité budgétaire, et le seul qui se prête naturellement à des délais d’intervention garantis : le prestataire s’engage sur un résultat, il organise ses moyens pour le tenir.

Cette prévisibilité a une condition : le prestataire doit connaître l’application avant de s’engager. Sans lecture du code, il n’a que deux options, se couvrir par une marge ou sous-estimer, et les deux se paient plus tard. D’où l’intérêt d’un audit ou d’une période de transition avant le régime courant. Le CCAG-TIC, cahier des clauses administratives générales des marchés publics informatiques, plafonne cette transition à six mois dans les marchés qui s’y réfèrent (article 38) ; un contrat privé fixe librement la sienne.

Le forfait a deux limites. Ce qui sort du périmètre se traite à part : le même texte prévoit que les opérations de maintenance non prévues au marché ne peuvent être effectuées qu’après accord du titulaire (article 39). Et un forfait mal dimensionné coûte dans les deux sens : trop large, vous payez une capacité que vous n’utilisez pas ; trop serré, chaque demande devient une discussion sur ce qui est inclus.

Quatre points se vérifient dans un contrat au forfait.

• Ce qui est inclus, famille de travaux par famille de travaux, et ce qui déclenche un devis.
• La règle qui sépare une anomalie, couverte, d’une évolution, facturée à part.
• Les niveaux de service : délais, plage d’intervention, mesure, et conséquence s’ils ne sont pas tenus.
• Le rapport qui montre ce que le forfait a réellement couvert, et la date à laquelle son montant se révise.

La régie : souple, avec le pilotage à votre charge

En régie, vous payez le temps passé par les intervenants du prestataire, sur la base d’un tarif journalier ou horaire. Le prestataire s’engage sur des moyens : des compétences, une disponibilité, la continuité en cas d’absence. Il ne s’engage ni sur un résultat ni sur un volume de travaux livrés : si une évolution prend deux fois plus de temps que prévu, c’est vous qui payez la différence.

La régie convient quand le besoin est difficile à décrire à l’avance : des évolutions qui se décident au fil de l’eau, une refonte progressive, une application dont le périmètre bouge. Elle convient aussi pour renforcer durablement une équipe déjà en place : c’est le modèle des développeurs dédiés. Elle suppose en revanche que quelqu’un, chez vous, exprime les besoins, fixe les priorités et valide le travail : sans ce pilotage, le temps se consomme sans cap. Si personne n’a ce rôle en interne, une direction technique à temps partagé peut le tenir.

Elle se prête mal aux engagements de délai sur les incidents. Un prestataire qui fournit du temps peut s’engager sur la disponibilité de ses équipes, rarement sur le délai de rétablissement de votre application. Si ce délai compte, c’est un argument pour mettre au moins le correctif au forfait.

Quatre garde-fous rendent une régie lisible.

• Un plafond par mois ou par lot, au-delà duquel rien ne se fait sans votre accord.
• Une estimation avant chaque demande importante, comparée ensuite au temps réel.
• Un relevé de temps détaillé par demande, et non un total par intervenant.
• Un point régulier où les priorités se fixent et où la consommation se lit.

Les unités d’œuvre : un barème entre les deux

Le modèle aux unités d’œuvre, qu’on appelle aussi carnet de tickets, part d’un barème : chaque type de demande vaut un nombre d’unités fixé à l’avance. Vous achetez un volume d’unités ; chaque demande est classée dans le barème, chiffrée en unités, validée par vous, puis décomptée du solde. Le coût d’une demande est connu avant qu’elle commence, comme au forfait ; le volume total suit votre besoin, comme en régie.

Tout repose sur le barème. Pour qu’il serve, il doit donner pour chaque type de demande une description et un exemple tiré de votre application, faute de quoi chaque estimation devient une négociation. Le crédit de temps, un volume d’heures acheté d’avance et décompté au temps réellement passé, en est une variante plus simple : il protège le budget global, pas le prix de chaque demande.

Ce que le contrat doit préciser :

• Le barème : les types de demandes, le nombre d’unités de chacun, un exemple concret pour chacun.
• Qui classe une demande dans le barème, et comment se règle un désaccord.
• La durée de validité des unités, et le sort de celles qui ne sont pas consommées : report, remboursement ou perte.
• Le suivi du solde, demande par demande, dans l’outil de tickets.
• La révision du barème après quelques mois, à partir des demandes réellement traitées.

Choisir selon la nature des travaux

Le bon réflexe est de partir des travaux, pas du contrat. Le CCAG-TIC distingue quatre familles de maintenance (article 38) : préventive, corrective, adaptative et évolutive. Elles ne se prévoient pas de la même façon, et ne se paient donc pas de la même façon.

Une frontière compte plus que les autres : celle qui sépare le correctif de l’évolutif. Une anomalie est un écart par rapport à ce que l’application devait faire ; une évolution change ce qu’elle doit faire. Quand les deux ne se paient pas de la même façon, cette règle doit être écrite, avec le nom de celui qui tranche en cas de doute. Notre guide de la maintenance évolutive détaille cette frontière.

Le modèle mixte : un socle au forfait, les évolutions à part

La réponse n’est pas forcément « forfait ou régie » : elle peut être « forfait et autre chose ». Le schéma le plus lisible met le préventif et le correctif au forfait, avec des niveaux de service, et paie les évolutions à part : aux unités d’œuvre si elles se ressemblent, en régie plafonnée ou au devis si ce sont des chantiers. Vous gardez un budget fixe pour ce qui fait tourner l’application, et une enveloppe pilotable pour ce qui la fait progresser.

Le modèle se révise avec le temps. Au démarrage, quand le prestataire découvre l’application, le volume réel est inconnu ; après quelques mois de demandes tracées, il se lit dans l’outil de tickets, et le forfait comme le barème peuvent être ajustés. Prévoyez au contrat la date de cette révision et les chiffres sur lesquels elle s’appuie. Notre guide pour externaliser sa maintenance applicative décrit les étapes de ce démarrage.

Les questions à se poser avant de signer

• Connaissez-vous le volume de vos demandes sur les douze derniers mois, par famille de travaux ?
• Le périmètre de l’application est-il stable, ou va-t-elle beaucoup évoluer ?
• Avez-vous besoin d’un délai garanti sur les incidents, et sur quelle plage horaire ?
• Qui, chez vous, fixe les priorités et valide les demandes ?
• Le prestataire connaît-il déjà le code, ou faut-il un audit et une période de transition ?
• Que devient ce qui n’est pas consommé : temps, unités, capacité du forfait ?
• À quelle date, et sur quels chiffres, le modèle se révise-t-il ?

Quel que soit le modèle retenu, les autres clauses ne changent pas : périmètre, sécurité, propriété du code, réversibilité. Notre guide du contrat de maintenance applicative les passe en revue.

Questions fréquentes

Un modèle se choisit, puis se révise

Forfait, régie ou unités d’œuvre : le choix se fait famille de travaux par famille de travaux, sur la base de ce que vous savez de votre application, et il se révise quand vous en savez plus. Le forfait achète de la prévisibilité, la régie de la souplesse, le barème un peu des deux. Ce qui compte, c’est que le contrat dise clairement ce qui est payé, ce qui est engagé, et comment le modèle évolue.

La maintenance applicative d’iones repose sur un forfait ajustable, suivi par un rapport de consommation, et l’équipe nearshore peut aussi renforcer la vôtre en régie, avec des développeurs dédiés. Pour savoir quel modèle convient à votre application, écrivez-nous.