20 développeurs, un taux horaire, et aucune idée de ce que le projet a vraiment rapporté

« Je connaissais le taux horaire de chaque développeur. Je connaissais le taux contractuel du client. J'ai soustrait l'un de l'autre et je pensais connaître la marge. Puis j'ai construit un compte de résultat par projet et j'ai réalisé que je dirigeais une entreprise sur une fiction depuis quatre ans. »

La fondatrice d'une entreprise IT de services et d'outstaffing — 20 développeurs, ₴36M de chiffre d'affaires annuel, sept clients actifs — a décrit l'exercice qui a changé sa façon de fixer ses prix et de recruter.

Pendant quatre ans, elle avait dirigé l'entreprise selon ce que tout le monde dans le secteur utilise : la logique du taux horaire. Chaque développeur avait un taux de coût (₴550/heure, en moyenne). Chaque client avait un taux contractuel (₴950/heure, en moyenne sur l'ensemble des clients). Une simple soustraction donnait ₴400/heure de marge brute par développeur, environ 42 % de marge. Extrapolé à toute l'équipe : confortable, rentable, en croissance.

Puis elle a fait l'exercice. Prendre un projet. Pas le chiffre « nous avons facturé au client ₴X de l'heure ». Le compte de résultat réel du projet. Le chiffre d'affaires client pour le mois. Tous les coûts directement imputables à ce projet. Tous les coûts indirectement imputables. Ce qu'il reste.

Marge du projet chez son client phare, sur les 12 mois précédents : 14 %. Pas 42 %.

Vingt-huit points de marge avaient disparu dans un ensemble de coûts que la logique du taux horaire ne touchait pas.

Ce que la logique du taux horaire cache vraiment

La logique du taux horaire suppose qu'un développeur est utilisé à 100 % sur le projet, productif à 100 % pendant ce temps, et que le projet ne consomme que son travail. Rien de tout cela n'est vrai pour une entreprise de services réelle. Banc et réduction progressive (−5 points). Quand un projet se termine ou qu'un client fait une pause, le développeur est inactif mais toujours payé. Deux semaines par an, en moyenne, par développeur. Non facturable. Vient en déduction de la marge.

Congés payés et arrêts maladie (−4 points). Les développeurs salariés bénéficient de congés payés et d'arrêts maladie. Le taux contractuel n'est facturé que lorsqu'ils travaillent. L'écart est invisible tant qu'on ne le compte pas.

Réunions internes, processus, entretiens d'embauche (−6 points). Standups, rétrospectives, planification, entretiens de candidats, synchronisations internes. Tout est payé, rien n'est facturable. En moyenne 4 à 6 heures par développeur et par semaine.

Outils et licences (−2 points). Licences d'IDE, infrastructure cloud pour les environnements internes, outils de gestion de projet, monitoring, plateformes de communication. Faible à l'unité ; ça s'accumule.

Recrutement et frais de gestion (−7 points). RH, delivery managers, chefs de projet, le temps propre de la fondatrice. Tous sont payés. Presque jamais facturables. C'était la plus grosse fuite isolée.

Remises et heures supplémentaires non facturées (−4 points). Le client a négocié le tarif au renouvellement, obtenant 8 % de remise. Le travail d'urgence effectué le week-end n'était pas toujours suivi. Les dépassements sur les portions à périmètre fixe ont été absorbés.

Vingt-huit points, six catégories, aucun dans la logique du taux horaire.

La reconstruction — le cadre du compte de résultat par projet

La fondatrice a construit son compte de résultat par projet en un week-end. C'est devenu le document le plus important de son entreprise. Le cadre s'applique à toute entreprise de services. Un — Chiffre d'affaires du projet. Heures facturées mensuelles × taux contractuel client. Pas l'engagé commercial ; le réellement facturé.

Deux — Coût direct du développeur, totalement chargé. Salaire + charges + avantages + amortissement du matériel + congés payés, divisé par les heures d'utilisation (et non les heures calendaires). Si un développeur est facturable 65 % du temps, son coût horaire totalement chargé est salaire/(heures × 0,65).

Trois — Coût alloué de gestion de projet, de delivery management et de recrutement. Part approximative selon la taille du projet ou le chiffre d'affaires. Pas besoin d'être parfait. Besoin d'être cohérent.

Quatre — Outils et licences imputables au projet.

Cinq — Allocation du banc. Coût total du banc pour l'année, réparti entre les projets actifs.

Six — Allocation des réunions internes et des processus. Pourcentage des heures payées consacrées à du travail hors projet × coût alloué.

Résultat — Marge réelle du projet. Pour son client phare : 14 %. Pour deux clients plus petits : 21 % et 8 %. Pour un client qu'elle pensait être son meilleur : 3 %.

Ce qu'elle a fait de cette vérité

Le client à 3 % a eu droit à une conversation sur une hausse de tarif. Ça s'est bien passé ; la marge est passée à 12 %. Le client à 8 % avait des problèmes de discipline de périmètre (sur-service) qui étaient corrigibles ; la marge est passée à 15 %. Les frais de recrutement ont été renégociés avec un forfait mensuel fixe au lieu de frais par embauche. Les réunions internes ont été auditées — trois réunions hebdomadaires récurrentes ont été supprimées. L'utilisation de deux de ses développeurs seniors est passée de 58 % à 72 % en les faisant passer d'un travail interne fortement chargé en banc à du travail client. La marge globale de l'entreprise est passée d'un apparent 42 % (fictif) à un réel 19 % (avant la reconstruction) puis à un réel 27 % (six mois plus tard). Plus important que le chiffre : elle savait désormais quel client était réellement rentable, lequel subventionnait le banc, et lequel lui coûtait discrètement de l'argent.

Le cadre — que suivre

Six chiffres, mensuels, par projet :

• Heures facturables réelles (pas les heures engagées ; les réelles)
• Coût totalement chargé du développeur par projet
• Frais de gestion alloués (temps PM/DM/recruteur/fondatrice en % du mois)
• Allocation du banc (coût du banc ce mois × part de chiffre d'affaires du projet)
• Marge réelle du projet (chiffre d'affaires − tout ce qui précède)
• Utilisation par développeur, suivie séparément de la marge

Six chiffres, un tableau de bord, revue mensuelle avec le delivery lead. Deux heures par mois, pour empêcher la fiction de revenir.

📌 Envie de voir si vos projets sont vraiment aussi rentables que le suggère votre calcul de taux horaire ? Envoyez-nous trois mois de données de facturation et la répartition des coûts de votre équipe — nous construirons la cascade de marge réelle par projet et vous l'expliquerons en 15 minutes. [Demandez votre diagnostic Finmap gratuit →]