Reprenons notre exemple de l’article précédent : d’un côté un salarié, Xavier, à 37 000 € nets annuels et de l’autre une freelance, Cécile, qui gagne 62 070 € nets annuels. Les deux sont sur le même type de poste, chez le même client et pour le même tarif de 500 € HT par jour. Seule différence : Cécile a choisi de ne travailler (enfin facturer) que 200 jours alors que Xavier en travaille 215.
Evidemment, sur le papier ça fait rêver 🙂 Mais on s’interroge : comment se fait-il, à poste et tarif égaux, que l’une puisse gagner presque 70% de plus que l’autre ? Rien n’étant gratuit dans ce monde, il y a bien évidemment plusieurs points qui font que la différence se justifie.
L’inactivité
C’est le plus gros facteur de risque pour les freelances. Xavier, ses congés sont payés ; quand il n’est pas en mission, il est en intercontrat peinard. Tous les jours où il n’est pas en mission, c’est sa SSII qui débourse. Et s’il se retrouve sans emploi, il a le droit de toucher le chômage.
Pour Cécile, chaque jour non travaillé est un jour non payé. Ce n’est pas très grave quand c’est anticipé mais les fois où ce n’est pas prévu et que ça dure, comme une sortie de mission non planifiée, ça peut faire mal. Et bien sûr, pas de chômage. C’est essentiellement à cela que sert le gap de rémunération : à provisionner pour les jours moins fastes et les coups durs.
Chaque jour non travaillé est un jour non payé. Et bien sûr, pas de chômage.
Par exemple, en 2017 j’ai travaillé seulement 8 mois (145 jours facturés). J’étais volontairement en congés de janvier à mi-février, d’une part pour souffler et d’autre part pour monter la société. Mais quand ma mission s’est brusquement arrêtée mi-juin, j’ai passé 2 mois et demi sans activité et donc sans revenu. A cause des délais dans les règlements de factures (voir paragraphe ci-dessous), je n’ai rien touché entre fin juillet et début décembre.
Les délais de paiement
Xavier, en fin de mois, sauf gros gros souci de son employeur, il est payé. C’est le principe du salaire. Cécile, elle, va attendre que son client veuille bien lui faire son virement. Une facture, ça peut se payer à réception mais aussi à 30, 45 ou 60 jours… et c’est souvent le client qui décide, même si c’est un facteur de négociation. Donc quand Cécile commence une mission le 1er juin, elle émettra sa facture le 30 juin et peut ne pas être payée avant le 31 août. Et encore, il ne faut pas que le client soit un mauvais payeur et qu’il faille le relancer régulièrement. Donc encore un facteur de risque à mitiger.
Les coûts de structure et fonctions supports
Lorsqu’il a un problème ou une question, le salarié va s’adresser au personnel de sa SSII. Pour la paie, un changement de carrière, la prise de congés, un changement de mission… il y a des personnes qui s’occupent de tout ça. Des RH, des responsables administratifs, des commerciaux. Et ces personnes-là, il faut les payer et cela engendre un coût.
En tant que freelance on a moins de coûts annexes, mais cela ne signifie pas que les problèmes n’existent plus.
Côté freelance, rien de tout cela. Quand il y a un problème, soit on se débrouille tout seul, soit on paie pour que quelqu’un le résolve à sa place. Une question sur la TVA ? Il faut se renseigner par soi-même ou avoir un conseiller (le comptable va souvent remplir ce rôle) que l’on va rémunérer. Il faut trouver une nouvelle mission ? Soit on y arrive seul via son réseau, soit on paie un intermédiaire commercial pour le faire. Si on choisit de tout faire soi-même, le travail à fournir viendra en plus de celui chez le client : il faudra prendre des jours hors mission et le chiffre d’affaires prendra un coup dans l’aile.
Donc en tant que freelance on a moins de coûts annexes, mais cela ne signifie pas que les problèmes n’existent plus. Par contre, on n’a pas besoin d’embaucher plusieurs personnes à temps plein non plus.
La couverture sociale
Là, on aborde un sujet un peu compliqué. Selon le statut de l’entreprise, la freelance va soit cotiser et bénéficier du régime général (statuts SAS/SASU), soit cotiser et bénéficier du régime social des indépendants (statuts SARL/EURL, professions libérales…), le RSI et tous ses copains. Dans le premier cas, les charges sont plus élevées et dans le second cas, la couverture est moins chère mais moins bénéfique notamment concernant la retraite. Ne maîtrisant pas complètement ce sujet, je ne vais pas m’étendre dessus, mais c’est un point à prendre en compte lors du choix du statut de l’entreprise.
Et puis il y a les autres assurances : mutuelle, prévoyance, retraite complémentaire… pour lesquelles les entreprises peuvent négocier des tarifs et des conditions intéressantes en raison du nombre d’employés. Pour le coup, la freelance va avoir du mal à obtenir les mêmes contrats que le salarié à prix égal. Mais elle va avoir l’avantage du choix et donc pouvoir faire faire des devis personnalisés, voire carrément choisir de ne pas prendre d’assurance du tout.
Bref, la différence de rémunération va aussi compenser une couverture sociale moins performante.
Qu’en conclure ?
Que tout n’est pas rose et qu’il faut en avoir conscience. Bien sûr, le gros gap de rémunération fait super envie mais il faut savoir ce qui se cache derrière. Comme partout, il n’y a pas de mystère : le risque paie mais il faut vouloir le prendre. Mais partir préparé(e) permet d’éviter les mauvaises surprises et de rester optimiste pendant les mauvais moments.
Et puis, à bien y regarder, que risque un freelance en IT dans une région qui embauche ? Peu voire pas d’inactivité, des tarifs attractifs et négociables, de multiples opportunités pour améliorer son réseau… et je ne parle même pas des aides de création d’entreprise, qui feront l’objet d’un prochain article. Le risque est donc faible dans ce cas, pour un gain non négligeable. A méditer.
Software developer since 2000, I try to make the right things right. I usually work with .Net (C#) and Azure, mostly because the ecosystem is really friendly and helps me focus on the right things.
I try to avoid unnecessary (a.k.a. accidental) complexity and in general everything that gets in the way of solving the essential complexity induced by the business needs.
This is why I favor a test-first approach to focus first on the problem space and ask questions to business experts before even coding the feature.
