Pourquoi votre TMA / AMS coûte-elle 10× trop cher ?
Le modèle TMA D365, conçu avant l'IA, est structurellement coûteux. Décryptage des mécanismes qui font exploser vos coûts et de la solution IA qui émerge.
Le modèle TMA : conçu pour une époque révolue
La TMA est née dans les années 1990, quand la maintenance d'un système ERP nécessitait physiquement des experts sur site, capables de naviguer dans des interfaces propriétaires complexes, de modifier des programmes en COBOL ou en ABAP, et de gérer des infrastructures on-premise critiques. Le modèle de facturation au temps passé était alors la seule option raisonnable : la complexité était réelle, imprévisible, et difficile à standardiser.
Triente ans plus tard, D365 Finance & Operations tourne sur Azure, dispose d'une documentation exhaustive, d'une API standardisée, et d'un langage (X++) dont les patterns sont bien documentés. Les outils ont radicalement changé. Mais le modèle économique de la TMA, lui, est resté identique : forfait mensuel + régie journalière pour les développements. Cette inertie n'est pas accidentelle — elle est profitable pour les prestataires.
Le paradoxe est frappant : d'un côté, Microsoft investit des milliards pour rendre D365 plus standardisé, plus documenté, plus facile à maintenir. De l'autre, les coûts de TMA n'ont pas baissé — ils ont souvent augmenté, à mesure que les prestataires ont consolidé leur position et que la rareté des experts D365 a maintenu les tarifs à la hausse.
Les 4 mécanismes qui gonflent votre facture TMA
Mécanisme 1 : la sur-staffing. Votre contrat TMA inclut souvent plus d'ETP que nécessaire, 'pour faire face aux pics'. En pratique, ces ressources sont partiellement mobilisées sur d'autres clients pendant les périodes creuses. Vous payez pour une disponibilité que vous n'utilisez pas à plein.
Mécanisme 2 : la complexification volontaire. Un prestataire TMA qui simplifie et automatise son propre travail réduit les heures facturables futures. Il n'y a donc pas d'incitation à optimiser, à documenter, ou à mettre en place des outils qui rendraient la maintenance moins coûteuse. Certains prestataires vont jusqu'à décourager activement les équipes internes de monter en compétence — préservant ainsi leur rôle d'intermédiaire indispensable.
Mécanisme 3 : le lock-in documentaire. En ne documentant pas correctement les customisations, en ne structurant pas les dépôts de code, en ne formant pas vos équipes internes, le prestataire TMA crée une dépendance structurelle. Changer de prestataire devient si coûteux (migration de connaissance, risque opérationnel) qu'il est souvent plus facile d'accepter la hausse de tarif annuelle.
Mécanisme 4 : la facturation des tickets réouverts. Quand une correction introduit un nouveau bug (phénomène de régression), le ticket est réouvert et refacturé. Dans un modèle où la qualité n'est pas garantie contractuellement, les régressions sont une source de revenus supplémentaires pour le prestataire.
Pourquoi l'IA renverse structurellement ce modèle
L'IA ne souffre d'aucun des quatre mécanismes décrits ci-dessus. Elle n'est pas sur-staffée (elle scale à la demande), elle n'a pas d'incitation à complexifier (son coût marginal est quasi nul), elle documente automatiquement tout ce qu'elle produit, et elle n'a pas d'intérêt à introduire des régressions (elle est payée au résultat, pas au temps).
Mais le changement le plus profond est dans le modèle de risque. Avec SKALP AI, vous payez 200 € par ticket résolu. Si le ticket n'est pas résolu de manière satisfaisante, il n'est pas facturé. Ce modèle aligne parfaitement les intérêts : SKALP AI n'est profitable que si vous obtenez des résultats. C'est l'antithèse exacte du modèle TMA.
De plus, chaque ticket généré par SKALP AI est documenté, testé, et versionné dans Azure DevOps. Il n'y a pas de lock-in documentaire — au contraire, la base de connaissance de votre D365 s'enrichit à chaque ticket résolu. Après 12 mois d'utilisation, vous avez une documentation exhaustive de toutes vos customisations, générée automatiquement. C'est un actif de gouvernance que peu d'entreprises possèdent aujourd'hui.
Comment migrer d'une TMA à un modèle IA : guide pratique
La migration d'une TMA vers SKALP AI n'est pas un big-bang. Elle peut se faire progressivement, sur 3 à 6 mois, sans rupture de service. Étape 1 : identifiez les 20 % de tickets les plus courants dans votre backlog — généralement des états, des automatisations simples, des modifications de formulaire. Testez SKALP AI sur ces tickets pendant 2 à 3 mois en parallèle de votre TMA existante. Mesurez les résultats (délai, qualité, coût).
Étape 2 : élargissez le périmètre aux tickets de développement de complexité moyenne. Réduisez simultanément le volume d'ETP TMA en conséquence. La plupart des contrats TMA permettent cette modulation si vous respectez les préavis contractuels. Étape 3 : renégociez votre contrat TMA résiduel pour le concentrer sur les activités à très forte valeur ajoutée (architecture, crises de production, intégrations legacy critiques) où l'expertise humaine reste indispensable.
À l'issue de cette migration, la plupart des DSI que nous accompagnons réduisent leur facture TMA de 60 à 75 % tout en augmentant le nombre de tickets résolus par mois. Le backlog se réduit, la satisfaction des utilisateurs s'améliore, et le DSI reprend le contrôle de son patrimoine applicatif. C'est le vrai bénéfice de la transition vers l'IA — pas seulement le coût, mais la posture.
Prêt à transformer votre D365 ?
Rejoignez les DSI qui résolvent leurs tickets D365 en 1h pour 200 €.