Combien un développeur vous rapporte réellement : la vérité sur la marge en outstaffing

«J'étais convaincu de gagner 40 % sur chaque développeur. La première fois que nous avons fait la répartition par personne, le résultat était de 11 %. L'écart, c'était le banc de touche, une dépense à laquelle je n'avais tout simplement jamais pensé.»

Ce sont les mots d'un dirigeant à la tête d'un studio d'outstaffing de 14 ingénieurs. Cette histoire est familière à presque quiconque loue une équipe à l'heure : le tarif client moins le salaire du développeur ressemble à du bénéfice. En réalité, la moitié de l'entreprise se cache entre ces deux chiffres — et tant que vous ne ventilez pas les coûts par personne, vous pilotez le chiffre d'affaires, pas la marge.

Pourquoi « tarif moins salaire » ment

Prenons un développeur de niveau intermédiaire typique. Vous facturez au client 35 $ de l'heure ; le développeur coûte environ 3 000 $ par mois après impôts. Dans la tête du dirigeant, cela donne 35 $ contre environ 20 $ — une marge proche de 43 %. Cela semble excellent, et c'est exactement ce chiffre sur lequel on s'appuie pour décider d'embaucher davantage, d'accorder une remise ou d'augmenter un salaire.

Le problème, c'est qu'un développeur ne livre pas 160 heures facturables par mois. Entre deux projets, il est sur le banc de touche. L'intégration d'un nouveau client mobilise une semaine, le temps que la personne se familiarise avec du code et des processus qui ne sont pas les siens. Ajoutez les réunions, les revues de code, la formation, les arrêts maladie, les congés. Le taux d'utilisation réel — la part des heures réellement payée par le client — dépasse rarement 75 % même dans les studios en bonne santé. Et chaque pourcentage non facturable, vous le financez de votre poche.

La répartition pour une personne

Comptons honnêtement, avec les mêmes chiffres.

43 % sur le papier sont devenus 12 % dans la réalité. Et c'est encore le bon scénario. Que l'utilisation tombe à 60 % à cause d'un mois creux, et ce même développeur passe dans le rouge — alors même que vous continuez à payer le salaire comme si de rien n'était.

Comptons sur une année complète

Le chiffre mensuel est trompeur, car le banc de touche n'est pas régulier. Prenons ce même développeur intermédiaire sur une année. Dix mois, il travaille à 80 %, un mois à 40 % (un projet s'est terminé, le suivant n'avait pas encore commencé), et une semaine au total part en arrêts maladie et en formation. Sur l'année, le client a payé environ 1 250 heures au lieu des 1 920 théoriques. Revenu : environ 43 750 $. Salaire avec charges : 36 000 $. Frais généraux par personne : 8 400 $. Bénéfice annuel généré par le développeur : environ −650 $. Ce même ingénieur qui « dégage 43 % de marge » a terminé l'année légèrement dans le rouge — tout cela à cause d'un mois creux et de quelques semaines non facturables étalées sur l'année.

«Le banc de touche n'apparaît sur aucune facture, donc personne ne le voit. Et il coûte plus cher que n'importe quelle remise accordée à un client.»

Trois coûts systématiquement sous-estimés

Premier coût, le banc de touche. Le temps entre deux projets, c'est vous qui le payez, pas le client. Une semaine creuse par mois, c'est 25 % de revenu en moins par personne, pour le même salaire. Dans un studio de 14 personnes, même un banc de touche moyen de 10 % revient à entretenir une personne et demie qui ne rapporte rien.

Deuxième coût, les heures non facturables au sein d'un projet. Stand-ups quotidiens, points avec le client, revues, recherches, reprises après un changement de périmètre. Le client paie pour 6 heures alors que 8 sont mobilisées. Ces deux heures par jour sont aussi un coût pour vous, simplement invisible.

Troisième coût, les frais généraux de management. Tous les cinq ou six ingénieurs, il faut un chef de projet, et recruter ou remplacer une personne coûte environ un mois de son salaire, plus les mois nécessaires pour que le nouvel arrivant atteigne sa pleine vitesse. Cet argent n'est rattaché à aucune facture précise, ce qui le rend facile à ignorer — jusqu'à ce que vous calculiez le bénéfice par personne après frais généraux.

À quoi cela ressemble dans la réalité

On entend ce problème dans des phrases typiques au sein du studio. « Nous avons beaucoup de projets, mais peu de bénéfice. » « Nous sommes passés à 20 personnes, mais le dirigeant gagne comme s'il en avait 12. » « Un client est parti — pas de souci, on met la personne sur un projet interne » (autrement dit, sur un banc de touche complet à vos frais). « Faisons 10 % de remise à ce client, il est important » — alors que la marge sur ce compte était déjà de 12 %, et que la remise le rend déficitaire.

Tout cela n'est que le symptôme d'une seule chose : le studio calcule l'écart tarif-moins-salaire et ne calcule jamais le bénéfice par personne après banc de touche et frais généraux. Le chiffre d'affaires est élevé, et le dirigeant se demande où passe le bénéfice.

Comment voir la marge de chaque développeur

Pour piloter cela, il faut voir le revenu et les coûts par personne ou par projet, pas dans une marmite commune. Dans Finmap, vous créez des projets et des axes, vous enregistrez le revenu du client et le coût direct de la personne qui réalise le travail — et vous voyez la marge brute par ingénieur et pour le studio dans son ensemble. Le banc de touche cesse d'être invisible : un mois creux apparaît immédiatement dans le rapport, au lieu d'être découvert six mois plus tard sous la forme d'un vague « le bénéfice a baissé, allez savoir pourquoi ». Vous voyez aussi quel client apporte une marge normale et lequel se contente d'occuper vos équipes presque gratuitement.

Voir aussi — en quoi la comptabilité de gestion diffère de la comptabilité générale en IT et comment mesurer l'utilisation d'une équipe.

Que faire

• Fixez une utilisation cible et surveillez-la chaque semaine, pas une fois par trimestre. Une semaine creuse repérée à temps peut encore être comblée par une vente.
• Intégrez le banc de touche dans le tarif : celui-ci doit couvrir non seulement les heures occupées, mais aussi les heures creuses inévitables. Si l'utilisation cible est de 75 %, le tarif est calculé à partir de ce chiffre, pas de 100 %.
• Mesurez le bénéfice par personne après frais généraux, pas l'écart brut tarif-moins-salaire. Seul le premier chiffre dit la vérité.
• Regardez la marge par client : un grand compte avec une remise rapporte souvent moins qu'un petit compte au tarif plein.
• Planifiez les remplacements et les embauches en fonction de la charge, pas « par précaution ». Chaque personne recrutée « pour la croissance » sans projet, c'est du banc de touche pur à vos frais.

L'outstaffing paraît un métier simple jusqu'à ce qu'on commence à compter par personne. Dès qu'on s'y met, on voit clairement qui gagne vraiment de l'argent, qui reste sur le banc de touche et où la marge fuit par les heures non facturables. Et les décisions d'embauche, de remise ou de nouveau projet se prennent alors sur des chiffres, pas sur l'impression qu'« il y a beaucoup de monde, donc tout doit bien aller ».

Money Doesn't Disappear. You Just Don't See It.

Essayez Finmap gratuitement pendant 14 jours et découvrez dès ce mois-ci la marge de chaque développeur et de chaque projet — sans assemblage manuel de tableaux.