Refacturé à l'effectif, payé par la mauvaise unité
Les services partagés, informatique, RH, finance, achats, sont refacturés aux unités opérationnelles par des clés grossières comme l'effectif ou le chiffre d'affaires. Une unité sobre qui utilise à peine le service subventionne alors une unité gourmande, la refacturation paraît arbitraire, et le centre de services ne reçoit aucun signal l'incitant à être efficace. Nous coûtons les services partagés par activité et par transaction avec le TDABC, pour que chaque unité paie ce qu'elle consomme réellement.
Le coût par activités guidé par le temps chiffre chaque transaction qu'un centre de services partagés réalise, une facture, un recrutement, un ticket, par les minutes qu'elle prend réellement, exceptions et manutentions manuelles comprises. Il remplace une refacturation à l'effectif par un coût par transaction défendable, montrant où l'automatisation paie et quels clients internes portent vraiment la charge de travail.
Pourquoi une clé à l'effectif trompe
Une clé grossière répartit, elle n'alloue pas. Un service partagé existe parce qu'il est moins cher de le faire une fois pour tous que plusieurs fois séparément. Le piège est la refacturation. Répartissez le coût par l'effectif, le chiffre d'affaires ou un pourcentage fixe et vous supposez que chaque unité consomme le service en proportion de sa taille, ce qui ne tient presque jamais.
Une unité enregistre trois mille tickets par an ; une autre en enregistre dix. Elles reçoivent la même facture. L'utilisateur léger subventionne discrètement l'utilisateur lourd, la refacturation ressemble à un impôt plutôt qu'à un prix, et la finance passe le cycle budgétaire à défendre un chiffre auquel personne ne croit.
Même effectif, usage opposé
Deux unités ont le même effectif, alors le service informatique partagé leur refacture le même montant. Sur le rapport de coûts, elles ressemblent à des consommateurs égaux du support central. La réalité est tout autre :
- Unité A : stable et autonome, peu de tickets, aucun système sur mesure.
- Unité B : trois applications spécifiques, trois fois plus de tickets, et l'essentiel du travail d'intégration.
Coûtez l'activité que chacune consomme et l'unité A paie bien au-dessus de son coût réel tandis que l'unité B paie bien en dessous, financée par les autres. Ce n'est pas un problème comptable, c'est une correction de prix.
Même facture, l'une finance l'autre
Exemple illustratif, chiffres fictifs pour montrer le mécanisme. Deux unités de 200 personnes chacune sont refacturées 420 000 € sur une clé d'effectif. Mais l'unité A génère 3 100 tickets par an et aucune application sur mesure, tandis que l'unité B en génère 9 400 et soutient trois applications spécifiques.
Le vrai coût TDABC ressort à 248 000 € pour l'unité A et 712 000 € pour l'unité B. Sur la clé d'effectif, les deux sont des postes identiques. Par la consommation, l'une paie un tiers de plus qu'elle ne devrait et l'autre à peine plus de la moitié de son coût réel. Seule une vue par activité rend la subvention visible, et discutable.
Le coût atterrit sur l'activité, puis l'unité
La démarche tient en quatre temps :
- Cartographier le catalogue de services : les activités que le service réalise vraiment, tickets, intégrations, paies, bons de commande, support applicatif, le travail que le budget paie.
- Coûter chaque activité par unité d'oeuvre : le TDABC fixe un coût par ticket, par run, par heure de support à partir de la capacité pratique, si bien que la capacité inutilisée devient visible au lieu d'être enfouie dans la refacturation.
- Attribuer à l'unité consommatrice : chaque unité porte le coût de ce qu'elle a réellement consommé, transaction par transaction.
- Publier les taux : des taux unitaires et une facture claire transforment la refacturation en prix interne, que les unités et le centre peuvent planifier et améliorer.
Une refacturation qui tient en réunion
Quand la refacturation reflète la consommation, la discussion budgétaire cesse de porter sur l'équité et commence à porter sur la demande. Les gros utilisateurs ont une raison de consommer plus intelligemment, les utilisateurs légers cessent de les subventionner, et le centre de services peut comparer ses taux unitaires et justifier ses effectifs par un chiffre plutôt que par un récit.
Le modèle est construit sur vos données et vous est remis, si bien que la refacturation reste à jour à mesure que la demande évolue. Et quand les robots et l'IA absorbent les transactions à fort volume, aucun de ces gains ne peut être valorisé sans un coût par activité établi au préalable.
Quand l'automatisation réécrit la refacturation
L'IA et l'automatisation entrent droit dans le travail qu'un centre de services partagés facture. La RPA solde les transactions à fort volume, les agents intelligents absorbent les tickets de premier niveau, et la capture intelligente réduit le temps de traitement d'une facture. Tout cela abaisse le coût par activité et déplace le mix vers les exceptions et le jugement, ce qui change à quoi ressemble une refacturation juste.
Rien de cela ne peut être valorisé sans une base de coût par activité établie d'abord. Les centres qui gagnent sont ceux qui connaissent déjà leur coût par transaction avant que l'automatisation ne le réécrive. Dans les services partagés et les centres de services globaux, le coût de servir une unité peut atteindre deux à trois fois celui d'une autre de même taille, parce que le volume de factures, la complexité des tickets et le mix de services se répartissent inégalement.
Questions fréquentes
Pourquoi refacturer les services partagés à l'effectif pose-t-il problème ?
L'effectif, le chiffre d'affaires ou un partage forfaitaire supposent que chaque unité consomme le service en proportion de sa taille, ce qui est rarement vrai. Une unité sobre qui utilise à peine le service finit par subventionner une unité gourmande, la refacturation paraît arbitraire, et le centre de services ne reçoit aucun signal sur ce qui cause vraiment son coût.
Qu'est-ce qu'une refacturation par activité ?
C'est refacturer un service partagé selon ce que chaque unité consomme réellement : tickets, transactions, projets, heures de support, chiffrés par activité avec le TDABC. Chaque unité paie son usage réel, si bien que la refacturation est transparente et peut être contestée ligne par ligne.
Cela ne va-t-il pas créer des disputes internes ?
En général cela les termine. Les disputes viennent des refacturations que personne ne sait expliquer. Quand une unité voit les transactions derrière sa facture, la conversation passe de savoir si la charge est équitable à comment consommer le service plus efficacement.
Cela s'applique-t-il au-delà de l'informatique ?
Oui. La même approche fonctionne pour toute fonction partagée : RH, finance, achats, moyens généraux et juridique. Partout où un coût central est réparti entre unités par une clé grossière, le coût par activités rend le partage défendable.
Combien de temps pour modéliser nos services partagés ?
Le Profit Check gratuit indique en 5 minutes où vos refacturations internes risquent le plus de s'écarter de la consommation, sans transfert de données. Un modèle complet par activité et par unité se construit ensuite en 4 à 6 semaines à partir de vos données.
Voir aussi
Qui utilise vraiment le service partagé ? Le Profit Check gratuit indique en 5 minutes où vos refacturations internes s'écartent le plus de la consommation, sans transfert de données. Ou écrivez-nous via la page de contact.
France · Afrique francophone
Faire le Profit Check