Forfait ou régie : quel modèle de TMA choisir ?

Le choix entre forfait et régie conditionne la façon dont vous allez piloter, budgéter et consommer votre contrat de TMA. Les deux modèles ont des forces et des limites très différentes. Cet article vous donne les critères concrets pour trancher, sans jargon inutile.

#Le forfait TMA : périmètre fixe, budget garanti

Dans un contrat TMA au forfait, le prestataire s'engage sur un périmètre de prestations défini contractuellement, pour un prix mensuel fixe. Le périmètre couvre généralement la maintenance corrective (résolution de bugs), la maintenance préventive (patches sécurité, montées de version mineures) et un volume limité de maintenance évolutive (petites améliorations fonctionnelles).

Le forfait fonctionne sur la base d'un crédit mensuel de jours-homme ou de tickets. Par exemple, un forfait TMA Symfony peut inclure un volume de jours-homme par mois, un SLA P1 défini, les montées de version mineures PHP et Symfony, et un rapport mensuel d'activité. Le tout pour un prix fixe, convenu à l'avance.

Le principal avantage est la prévisibilité. Le DSI connaît exactement le coût annuel de sa maintenance applicative. Il peut l'inscrire dans son budget sans provision pour dépassement. Le SLA est contractuel : si le prestataire ne tient pas ses engagements, des pénalités s'appliquent.

Mais cette prévisibilité a un coût : la rigidité. Toute demande qui sort du périmètre contractuel (nouvelle fonctionnalité majeure, refactoring, migration) nécessite un avenant, avec un délai de négociation et un surcoût. Dans un contexte où les besoins évoluent vite, le forfait peut devenir un frein.

#Quand le forfait est le bon choix

Le forfait TMA est pertinent dans quatre situations précises. Premièrement, lorsque l'application est stable : elle est en production depuis plus de 12 mois, les fonctionnalités sont figées, les évolutions sont rares. Deuxièmement, lorsque le périmètre est clair : la DSI sait exactement ce qu'elle attend du prestataire, les SLA sont définis, les processus sont documentés.

Troisièmement, lorsque le budget est contraint : le contrôle de gestion exige un montant fixe, sans variable. Quatrièmement, lorsque la maintenance est essentiellement corrective et préventive, avec peu ou pas d'évolutions fonctionnelles.

Le forfait convient surtout aux applications métier internes qui ont atteint leur maturité fonctionnelle.

#La régie TMA : flexibilité et facturation au réel

Dans un contrat TMA en régie, le client achète du temps de développeur, facturé au TJM (Taux Journalier Moyen). Il n'y a pas de périmètre figé : le client priorise les sujets mois après mois, en fonction de ses besoins réels. Un mois peut être consacré à la correction de bugs critiques, le suivant à l'implémentation d'une nouvelle API, le troisième à un chantier de refactoring.

La régie offre une flexibilité totale. Le client peut réorienter les efforts à tout moment sans avenant contractuel. Il peut augmenter ou réduire le volume de jours consommés en fonction de son budget disponible. Il bénéficie d'une transparence totale sur le temps passé, puisque chaque tâche est trackée et reportée.

En revanche, la régie demande un pilotage interne plus fort. Le client doit prioriser les demandes, valider les estimations, suivre la consommation de jours. Sans product owner ou chef de projet dédié côté client, la régie peut dériver : les jours sont consommés sans vision d'ensemble, les priorités changent chaque semaine, le budget explose.

Le TJM en régie TMA varie selon le profil et la technologie. Chez Nehos, le développement en régie est facturé 275 € HT par jour. Ce tarif inclut le suivi de projet et les outils de suivi.

#Quand la régie est le bon choix

La régie s'impose dans trois contextes. Premier contexte : l'application évolue fréquemment. Une roadmap produit active, des demandes de fonctionnalités régulières, un marché qui bouge — le forfait ne peut pas absorber cette variabilité. Deuxième contexte : la phase de R&D. Quand l'entreprise explore de nouvelles fonctionnalités (intégration IA, refonte UX, nouvelle API), le périmètre ne peut pas être défini à l'avance.

La régie permet de tester, itérer, pivoter. Troisième contexte : le client dispose d'un product owner ou d'un chef de projet capable de piloter la relation au quotidien et de prioriser les demandes de façon structurée.

#Comparatif forfait vs régie : les 10 critères décisifs

Ce tableau met en évidence que les deux modèles ne répondent pas aux mêmes besoins. Le forfait optimise la prévisibilité, la régie optimise la flexibilité. Le choix dépend de la maturité de l'application et de la capacité de pilotage du client.

#Le modèle hybride : le meilleur des deux mondes

Nous recommandons de plus en plus un modèle hybride qui combine un socle forfaitaire pour la maintenance courante (corrective + préventive) et une enveloppe en régie pour les évolutions fonctionnelles.

Concrètement, cela se structure ainsi : un forfait mensuel (à partir de 750 €/mois pour la maintenance logicielle) couvre les corrections de bugs, les patches sécurité, les montées de version mineures et le monitoring applicatif. En parallèle, une enveloppe en régie de quelques jours par mois (à 275 € HT/jour) est dédiée aux nouvelles fonctionnalités, aux intégrations d'API et aux chantiers d'amélioration continue.

Ce modèle offre la prévisibilité budgétaire du forfait sur le socle de base, tout en conservant la flexibilité de la régie pour les évolutions. Le client sait que sa maintenance de base coûtera toujours le même prix, et il ajuste l'enveloppe régie mois par mois selon ses priorités.

Ce modèle réduit les frictions contractuelles (moins d'avenants), améliore la réactivité (pas d'attente de validation pour les évolutions) et donne une vision claire du coût total de possession de l'application.

#Grille tarifaire Nehos : forfait et régie TMA

Pour donner des repères concrets, voici les tarifs de base pratiqués par Nehos.

#Forfait de maintenance

La maintenance logicielle démarre à 750 €/mois HT. Le niveau de service (corrective seule, corrective + préventive, ou complète avec évolutions) et le volume de jours inclus se définissent selon votre application, sa stack et ses exigences de SLA. Le chiffrage se fait sur devis, en 48 h après un premier échange.

#Régie TMA

Le développement en régie est facturé 275 € HT/jour.

Ces tarifs sont indicatifs et varient selon la complexité de la stack, le volume engagé et la durée du contrat. Un engagement plus long peut ouvrir droit à des conditions plus favorables.

Pour une estimation précise adaptée à votre contexte, consultez notre guide complet sur le coût d'une TMA applicative en 2026.

#Les erreurs à éviter dans le choix du modèle

L'erreur la plus fréquente est de choisir un forfait rigide pour une application en pleine évolution. Le client finit par accumuler les avenants (un par nouvelle fonctionnalité), ce qui annule la prévisibilité budgétaire qui motivait le choix du forfait. Au bout de 6 mois, le coût total dépasse celui d'une régie, avec la complexité contractuelle en plus.

L'erreur inverse existe aussi : choisir la régie pour une application stable qui n'a besoin que de corrections ponctuelles. Le TJM étant plus élevé que le coût au jour d'un forfait, la régie revient plus cher pour un périmètre simple et prévisible.

Autre piège : le forfait sous-dimensionné. Un forfait qui ne couvre que quelques jours-homme par mois ne permet pas de traiter un incident P1 complexe (qui peut nécessiter plusieurs jours d'investigation et de correction). Le prestataire consomme alors son budget mensuel en un seul incident, et le reste du mois est non couvert. Mieux vaut un forfait correctement dimensionné qu'un forfait low-cost qui ne protège pas.

Enfin, négliger le pilotage en régie est une erreur coûteuse. Sans priorisation structurée des demandes, les développeurs travaillent sur des sujets non critiques tandis que les vrais problèmes s'accumulent. La régie sans gouvernance, c'est un robinet ouvert sur le budget IT.

#Comment passer d'un modèle à l'autre

Il est tout à fait possible de démarrer en régie et de passer au forfait une fois que le périmètre est stabilisé. C'est même une approche que nous recommandons pour les reprises d'applications. La régie permet de découvrir le périmètre réel de maintenance (volume de tickets, complexité des corrections, fréquence des montées de version), et ces données servent ensuite à dimensionner un forfait précis.

Inversement, un client sous forfait peut demander un passage en régie si ses besoins d'évolution augmentent brutalement (lancement d'un nouveau produit, intégration d'un partenaire, obligation réglementaire). Le passage se fait généralement en fin de période contractuelle, avec un préavis.

Nous cherchons à assurer la continuité de service lors de ces transitions : le même développeur reste affecté au projet, seul le mode de facturation change. Il n'y a pas de perte de connaissance ni de rupture de service.

#Conclusion : le modèle dépend de votre contexte, pas d'une doctrine

Il n'y a pas de modèle universellement meilleur. Le forfait est le bon choix pour la stabilité et la prévisibilité. La régie est le bon choix pour la flexibilité et l'innovation. Le modèle hybride combine les deux pour les contextes complexes.

Le vrai critère de décision n'est pas le prix, mais la maturité de l'application et la capacité de pilotage du client. Une application stable + un budget contraint = forfait. Une application en évolution + un product owner actif = régie. Une application critique + des besoins mixtes = hybride.

Pour déterminer quel modèle correspond à votre situation, prenez 15 minutes avec nos experts TMA. Nous vous donnerons une recommandation objective, chiffres à l'appui.

Photos : Artem Podrez, Christina Morillo sur Pexels.