La rentabilité d’une ESN

Bon, je ne vais pas me faire des amis avec cet article, mais j’avais envie de remettre les choses à leur place.

Récemment j’ai reçu un « inmail » sur Linkedin d’un recruteur me vantant les mérites de son entreprise : une énième « entreprise libérée » de la tech où cette fois, en plus des baby foots et des fruits (je caricature, mais à peine), les salaires sont libérés.

D’un œil extérieur, pour un jeune diplômé qui ne connait pas le système, le discours est séduisant :

• Un salaire de base (à priori un peu inférieur au standard du marché même si ce n’est pas explicité).
• Un variable pouvant aller jusqu’à 20% (ça a diminué, dans une première version du site de l’entreprise c’était 25%) réparti en deux parties
  • 12% de la « marge brute » mensuelle rapportée par le développeur, sans conditions
  • 8% de la MB mensuelle si l’indice de satisfaction du client dépasse 76% ; 2,4% pour une note entre 58 et 76, et rien en-dessous.
• Une organisation full agile dans laquelle il n’y a aucun projet en cycle en V avec les clients, aucune AT
• Des « inutiles » réduits au minimum car les employés ont une heure par jour pour travailler sur des sujets transverses de type outils, avant-vente, organisation interne, R&D, … (je vous épargne le jargon à la mode de squads, teams ou que sais-je)

Donc, le développeur junior peut se dire :

• J’ai un salaire net de base de 2000 euros – soit comme dit dans leur exemple, un prix de revient de 192
• Je suis vendu à un TJM de 400 eur/jour et donc à la fin du mois, en ayant bien travaillé tous les jours, je touche 20% des 208 euros, X 22 jours, /1,83 pour avoir le net, … cela fait 500 euros.
• Soit (c’est quand même plus clair comme cela) un équivalent de salaire brut de 38k annuel. Génial. Qu’est-ce que ce patron est généreux, reconnaissant de ma valeur. Quel concept win-win !

C’est triste, car la réalité est toute autre. Nous allons le voir sur plusieurs plans.

1. La réalité financière : pas tant de gain que ça
2. La réalité de l’ambiance : les heures, la compétition interne
3. La réalité des projets : les non-paiements, les petits clients
4. La réalité de l’impuissance : ou comment on signe des projets informatiques
5. La réalité du patron, ou l’explication globale du système « libéré », promise par cet article : un système bien plus sécurisé que l’ESN classique

La réalité financière

Quiconque a travaillé en SSII – oh pardon j’avais oublié qu’il faut dire « ESN » maintenant, nous sommes passés d’un jargon sans signification à un autre – sait que le taux d’activité des employés est toujours très loin des 100%. Nous le verrons au point 5) avec des chiffres plus précis, mais si c’était le cas, tous les propriétaires de SSII deviendraient multi millionnaires très vite…

Le taux d’activité moyen est de l’ordre de 75 à 80% – voire moins dans les activités de conseil (mais elles compensent avec une marge brute plus élevée). La maladie, l’intercontrat, les pertes de prod, les formations.. viennent diminuer l’activité.

Si par chance, l’employé faisait toute son activité sur les mêmes mois, il aurait donc son bonus pendant 9 mois sur 12, et rien les autres mois.

Mais en réalité, la répartition sera plutôt du style :

• 6 mois à 100%
• 2 mois à 70%
• 3 mois à 50%
• 1 mois à 20%

Dans la pratique, cela veut dire, en gardant le même exemple de TJM de 400 :

• 6 mois avec 500 eur de bonus
• 2 mois avec 210 eur de bonus (il faut faire la différence avec le prix de revient à 192, donc on ne gagne pas 70% des 500 eur !)
• 3 mois avec quasi rien (20 eur)
• 1 mois avec 0

TOTAL : 3480 euros, soit une moyenne de 290 eur par mois.

Si on repasse en annuel : un équivalent de salaire fixe de 34,5K au lieu de 33k dans une SSII « classique », mais avec une pression de dingue.

La réalité de l’ambiance

Qui n’a pas rêvé d’une douce entreprise socialo-macroniste dans laquelle, à on bichonne ses employés en leur fournissant des conditions de travail généreuses ET EN MÊME TEMPS, on récompense les meilleurs éléments par des bonus justes.

La réalité est toute autre : toute mise en place de suivi de la productivité par employé a un impact désastreux sur la coopération et sur l’autonomie des employés. Non pas en tant que tel (c’est bien de mesurer la productivité personnelle, même si cela confirme souvent ce qu’on sait déjà), mais à cause des effets pervers. Je le sais pertinemment car j’ai vécu cette mise en place de nouveaux outils de suivi, en tant qu’employé d’ESN, et aussi chez un client.

Il y a du positif : en suivant la rentabilité, on se rend compte que la productivité de chacun est grevée par un tas de sujets non productifs : des réunions, des avant-vente trop poussées, des études techniques inutilement complexes, de la R&D trop décalée par rapport aux besoins. On peut agir sur ces points.

Mais rapidement, et puisque tout le monde fait le ménage là-dedans, il faut trouver d’autres relais de performance : les objectifs de rentabilité sont en effet posés par rapport à la rentabilité moyenne de l’entreprise. Si l’on veut être augmenté plus, il faut figurer dans le haut de la liste. J’ai aussi connu une entreprise où le bonus n’était pas lié à la performance personnelle, mais à celle du service : les effets étaient les mêmes mais à l’échelle des relations inter services. Voici les effets constatés :

• « Ah non, je ne peux pas passer 2h à t’expliquer ce sujet, sauf si tu me donnes un code projet pour imputer le temps que je passe avec toi sur TON projet » : il ne faudrait pas baisser sa rentabilité en passant du temps pour les autres.
• « Désolé chérie, ce soir je reste jusqu’à 21h : on est le 29 du mois et nous sommes en retard dans la livraison du lot 3, si je ne rattrape pas avant la fin du mois, je ne toucherai pas mon bonus ». Ah mais j’oubliais, si le patron est encore plus machiavélique, il va embaucher surtout des célibataires geeks, et ce conflit sera évité !
• « Avons-nous vraiment besoin de cette 2^e phase de test ? Pour moi la qualité est satisfaisante, et si nous la zappons, cela fera plus de bonus pour nous tous ». D’ailleurs en fait mon temps de dév a explosé, donc je n’ai déjà plus de temps pour faire les tests.
• Ah mais j’oubliais : pas grave, comme on est en agilité, c’est le client qui va payer pour notre dérive en temps de dév : comme ça pas besoin de savoir si le problème vient d’une sous-estimation de notre part, d’une cadence trop faible chez nous, ou d’une spéc trop vague : de toute façon c’est lui qui paye. Ah vraiment, vive l’agilité, et surtout les clients pigeons.
• « Je ne vais pas passer de temps à réécrire tout ce code laid : il marche et sa ré écriture n’apportera pas de valeur fonctionnelle. » Et oui, pourquoi prendre en charge de la dette technique qui pourrait faire diminuer ma rentabilité, alors que cela pourrait retomber sur le suivant… il n’aura qu’à ne pas oublier cette refonte dans le chiffrage.
• « Je suis désolé, mais la perte de production, est due aux développeurs. En tant que scrum / directeur de l’entreprise / personne qui a les clés du système de pointage, je considère que la perte doit être porté par untel et untel ». Si en plus ça peut être ceux que je trouve un peu flemmards, ça peut être bien. Oui parce que bon, on le verra en 5), mais dans la vie réelle, il y a des pertes de prod et il faut bien les imputer sur quelqu’un.

Même dans le cas (idéaliste) où l’entreprise arriverait à vendre 100% de ses projets en agilité, il y aura forcément des fins de projets où le client demandera un rabais à cause d’un retard, ou refusera de payer la dernière semaine de sprint parce que « elle n’a fait que corriger des bugs qui n’auraient jamais du être là, nous n’allons pas en plus payer pour des bugs qui n’auraient jamais dû arriver ». Est-ce que dans ce cas-là, le taux de production des développeurs tient compte de ces jours non payés ? J’ai un gros doute…

• « Attends, toi je t’aime bien, je te mets sur le projet truc, son TJM est carrément plus élevé ». Ça tombe bien, j’avais vraiment envie de faire de la lèche pour aller sur les projets qui vont maximiser mon bonus.
• « Non mais tous ces dialogues fictifs n’arrivent pas chez nous, nous sommes bienveillants, chacun veille à ce que l’autre soit récompensé équitablement ». Et la marmotte ? Même si les gens ne sont pas venus pour l’argent, mettez de l’argent au cœur des relations inter personnelles, et vous verrez de la compétition. Il suffit de regarder ce qui se passe pour les commerciaux.

Le temps perso

Ah j’avais oublié un autre point : comme on est une super entreprise, on met en commun nos expériences et on monte une intégration continue qu’on réutilise, des processus agiles, des meetups pour que chacun expose aux autres ce qu’il a appris. Et surtout, les fonctions support, elles sont co-construites, viva el lider maximo youhou !

Source : publi-rédactionnel sur https://www.usine-digitale.fr/article/thetribe-les-guerriers-nantais-du-web-decroche-un-million-et-debarque-a-paris-lille-et-toulouse

Sauf que tout cela prend du temps. Mince, du temps non vendu !

Comment faire ? Le patron : « j’ai une idée géniale. On va leur raconter qu’on leur offre 1h par jour pour travailler sur ces sujets là. Alors qu’en fait on leur colle du travail qui va dégrader la rentabilité de leurs projets, car il n’a rien à voir avec le projet en cours en terme fonctionnel ou/et technologique, et va fragmenter leurs semaines. Mais comme on va mettre des mots magiques « R&D » ou « amélioration » ils vont être contents. »

Vous avez deviné la suite : le temps étant non vendu :

• Soit il faut compresser au maximum ces tâches transverses car elles ont tendance à déborder, et empêchent de réaliser la partie technique.
• Soit il faut faire des meetups le midi, le soir à 18h00 ou plus tard

Par contre pour le patron, c’est tout bénèf : les salariés s’investissent dans des squads « transverses » de type commerce ou avant-vente. Donc pas besoin d’avoir des personnes dédiées à ces activités là, des improductifs qui coûtent chers. C’est génial en plus : si cela est porté par les développeurs, c’est « scalable » : chaque développeur porte sa part de frais généraux. Que l’entreprise grandisse ou diminue, je maitrise ces coûts. Et je ne suis pas embêté lorsque à 50 personnes il faudrait que j’ai 1,5 personne administrative : à 2 j’aurais surpayé, à une elle aurait fondu les plombs, à 1,5 j’aurais du ajouter une demi tâche qui n’a rien à voir et j’aurais galéré à recruter… Là j’ai réparti la charge sur 4 développeurs et c’est réglé. Ni vu ni connu !

La réalité des projets

Dans un regard symétrique, nous savons que l’avis du client ne sera pas forcément meilleur parce qu’il est en agilité. En fait, ce mythe de l’agilité qui rend heureux les clients, c’est n’importe quoi.

D’abord parce que pour des raisons juridiques, d’organisation, de distance, de temps disponible… la plupart des clients ne sont pas passés à l’agilité, ne le feront jamais, et n’ont pas d’intérêt à le faire : pour tous les projets de sous-traitance au forfait en fait.

Et les sociétés qui sont prêtes à lancer un sujet sans savoir le budget, ou la date (pour être agile, il faut pouvoir faire bouger l’un des deux) ne sont pas légion. Alors oui, et cela se voit dans la liste des clients de cette entreprise « libérée », on trouvera… des pros de l’informatique. D’autres SSII ou agences (réponse conjointe à un appel d’offre), des startups cherchant une boite pour faire rapidement un MVP de leur produit V2, des éditeurs de logiciels assez matures pour accepter que la nouvelle version ne contiendra… que ce qui est fini de développer.

Oui, ces bons clients pour l’agilité existent. Mais ne nous leurrons pas : ils ne sont pas et ne seront pas majoritaires. Ils ne sont pas et ne seront pas des gros projets : de toute façon agilité et gros projets, comme dans « SAFe », c’est en totale contradiction. Le concept de cette boite ne va donc pas révolutionner le monde des ESN.

Donc quelle est la réalité de cette « entreprise à salaire libéré » : vous allez travailler pour des petites startups qui n’ont pas un rond, et veulent un super produit pour pas cher. C’est une belle opportunité pour apprendre une nouvelle technologie ou participer à la construction d’un produit hi-tech. Mais en aucun cas, ça ne sera un projet fondamentalement différent de ce qui existe dans les autres ESN.

Si vous avez de la chance, le cahier des charges est clair.

Si vous en avez moins, vous avez affaire comme ça m’est arrivé à une startup qui commence à peiner à boucler ses fins de mois. La sortie du produit devient donc urgente, ils veulent de l’agilité. Les spécifications, il n’y en a pas, puisque c’est agile : à partir d’un ticket JIRA de trois lignes, vous devez vous approprier le fonctionnel et essayer de réussir à contacter le co-fondateur, qui est surbooké mais est toujours le seul à avoir la vision complète du fonctionnel souhaité. Ah et au fait, vous alertez le client sur le fait qu’un PO disponible 25% de son temps, pour quatre développeurs au total (2 back + deux front) ce n’est carrément pas assez, il faudrait au moins deux fois plus. Mais lui n’est pas content et vous répond qu’il est déçu de vos développeurs, qui ne s’impliquent pas assez et ne s’approprient pas assez le fonctionnel.

Mais bon, c’est agile, et pas du cycle en V. En plus on utilise la dernière version de Java et on fait du TDD car le code est partiellement généré à partir de la définition des web services.
Donc c’est mieux. Ou pas.

Bref, qui dit petits projets faussement agiles, dit soirées à rallonges, ou retards. Le mythe de la startup qui a réussi sa levée de fonds et a plein d’argent à dépenser à la vie dure : mais celles là sont occupées à essayer de recruter en interne et de s’organiser : les startups qui sous-traitent leur dévs sont celles encore en phase expérimentale.

Ça peut être la vie rêvée de développeurs juniors : passer d’une startup à l’autre tous les 6 mois et apprendre beaucoup. Mais de là à dire que c’est magique parce que c’est agile, heu.

La réalité de l’impuissance

Derrière cette face cachée des projets et de la rentabilité, se cache aussi une souffrance du développeur, qui ne sera pas supprimée par cette organisation « libérée » : son impuissance à peser sur la stratégie de l’entreprise.

Alors quoi, encore ce ronchon, pourtant les captures d’écran plus haut prouvent l’inverse ! Cette entreprise valorise la contribution de ses collaborateurs, au lieu de déléguer à des experts dont c’est le métier, la gestion des RH, du commerce, de l’administratif, etc… (Bon, ils ont quand même un recruteur et un DAF, parce que faire faire ça par des dév, ça ne marche pas).

J’avoue, la recette est géniale, on en reparlera au point 5 : au lieu d’avoir un 20% ou 22% de frais qui vont augmenter et plomber la rentabilité si l’activité baisse, on la répartit sur des développeurs à hauteur de 13% (5 heures par semaine sur 35 à 40), on garde quelques pourcents liés aux locaux, DAF et recruteur… et globalement, on a « agilisé » le système car un départ de développeur fera baisser les frais fixes !

Alors pourquoi je dis que c’est de l’impuissance ? Parce que derrière tout le blabla socialo-communiste, il reste une seule réalité : il y a un ou des patrons qui ont pris des risques financiers, et qui en retour reçoivent une partie du travail de leurs employés. Et puis de l’autre côté il y a des employés qui quoi qu’on leur laisse penser, n’ont pas d’impact réel sur l’entreprise.

J’ai dit réel.

Parce que oui, vous pouvez laisser les employés s’auto organiser sur :

• Comment on va gérer les codes projets ?
• Comment on va répartir les bonus (dans la limite de la valeur fixée par le patron quand même faut pas déconner)  ?
• Comment on va réaliser les powerpoint de l’entreprise et le site ?
• Sur quelles valeurs on va communiquer ?
• Et même, ce qui ressemble à de la stratégie : quel type de compte on veut adresser ? sur quelle technologie on va se former ?

Mais en réalité, qu’est-ce qu’une ESN ? C’est une association de développeurs (en tout cas de gens qui travaillent sur des projets informatiques), qui attendent que des commerciaux leurs trouvent des projets. Pas de commerce, pas de projets.

Au final, le commerce décide de qui il démarche.

Le commerce décide de la remise qu’il fait au client : oh mince, cela va impacter votre joli TJM et donc votre bonus. Dommage !

Le commerce décide… enfin non, le client décide du projet qu’il veut : si plus personne ne veut de Symfony un jour, vous aurez beau avoir décrété dans votre squad que c’est le plus beau framework du monde, vous ne vendrez plus un seul projet dans cette technologie.

Pas de commerce, pas de projets. Si vous êtes en « interco forcée », qui perd du bonus ? Vous la sentez venir, la pression pour vous mettre à travailler sur n’importe quel projet même le plus pourri, histoire de toucher votre bonus ? Alors, peut être pas le premier mois, mais très vite la pression va revenir. 290 euros de différence par mois, ce n’est pas rien.

D’ailleurs c’est marrant parce que l’histoire des ESN est elle aussi un perpétuel recommencement. Dans les années 2000, du temps de l’AT AT AT partout, les SSII « vendeuses de viande » du style Alten utilisaient déjà une technique de bonus. C’était vendu différemment : vous avez un fixe de 35K. Et puis au lieu de vous mettre à 37 comme le concurrent, je vous donnerai un « frais de déplacement et de repas » bidon qui sera fixe à 15 euros par jour. De cette façon, vous aurez un équivalent de 38-39k et en plus, vous ne paierez pas d’impôt sur cette partie de votre salaire. Plutôt intéressant pour un célibataire ! Ah mais petit détail que j’ai oublié de vous dire, si vous n’êtes pas en mission, vous ne toucherez pas ces frais, c’est logique… Tiens tiens, ça me rappelle le système de cette entreprise libérée. Le bonus est calculé sur du projet, au lieu de l’AT, mais il revient au même : je suis prêt à offrir un petit peu de salaire en plus à un bon employé, en contrepartie d’être certain de limiter la casse avec un « mauvais » ou surtout en cas de retournement de la conjoncture.

Rien de plus frustrant pour un développeur que de finir sans son bonus parce que le commercial n’a pas été capable de trouver un projet en Symfony, ou parce que le client a fait n’importe quoi et refuse de terminer un projet agile.

Dans une ESN, le vrai pouvoir sera toujours au commercial, car c’est lui qui fait rentrer l’argent. Même le patron finira par négocier avec ses exigences, car il a besoin de faire rentrer du CA. C’est simple.

La réalité du patron

Et maintenant, des chiffres précis pour comprendre pourquoi, au final, il y en a un qui fera toujours une bonne affaire, et c’est le patron. Loin de moi l’idée de dire que ce n’est pas légitime : il a construit l’entreprise, et je ne suis pas un gaucho. Mais autant pour une entreprise capitalistique qui demande de forts investissements, il parait normal que la personne qui a amené l’argent soit dédommagée.

Autant pour une activité où on vend du service, des cerveaux humains, (et un petit peu d’intégration continue mais on connait tous la différence entre le discours commercial et la qualité réelle du code en centre de services et des tests), le patron n’a pas fait grand-chose à part réunir des commerciaux et des dévs. C’est déjà beaucoup, me direz-vous.

Ces calculs vont expliquer pas mal des choix « libérés ».

Tout d’abord, il faut revenir aux basiques de la rentabilité d’une ESN. Les coûts humains représentent la grande majorité des coûts, peut-être de l’ordre de 85%. La rentabilité est faible par construction.

Voici une grille type de rentabilité pour une ESN de 100 personnes

• Vente moyenne du collaborateur : TJM 450 euros / jour

• Le collaborateur me revient à 270 euros chargé par jour (logique : 40 000 / 218 x 1,47)

• Marge brute vendue : 180 euros – c’est-à-dire 40%

• Coûts de structure : 21% : locaux, entretien, SI interne et PC, commerciaux, services généraux

• Pertes : 16%
  • Pertes de production sur le forfait de l’ordre de 16% mais seulement 1 projet sur deux au forfait, on complète par de l’AT
  • Intercontrat 8%

• Marge nette : 3%

De ces chiffres, il ressort plusieurs leçons :

• Une petite variation des pertes peut faire passer l’entreprise de la banqueroute au faste : la tenue des projets est primordiale
• Les frais généraux coûtent beaucoup moins chers que les salaires, néanmoins, il est plus facile de gagner de la rentabilité sur les FG, car les profils de dév sont durs à avoir et doivent être payés au marché.
• Pas possible d’augmenter le salaire de quelqu’un sans augmenter son TJM, sinon en 1 an avec une augmentation de 3%, j’ai bouffé ma marge nette ! Donc obligation d’y aller très très mollo sur les augmentations.
• Si je peux acheter les locaux et que du coup les 5% (chiffre au pif) de frais dus aux locaux reviennent dans ma poche, je vais gagner beaucoup plus que par la marge nette : donc l’activité « d’entrepreneur » d’ESN est avant tout une affaire de financier de l’immobilier ! Ce qui explique le patron qui roule en gros 4×4 alors que les bénéfices sont à 0.

Nous en déduisons pas mal d’explications sur la générosité du patron socialiste :

• Lorsque je donne 20% de la marge générée au-delà d’un certain niveau, en fait je « troque » de la perte (en moyenne à 16% mais cela peut être beaucoup plus) contre un niveau de dépense figé et garanti. Qu’est ce qui est le mieux pour moi ?
  • 16% de pertes moyennes qui peuvent varier, d’un projet à l’autre, de 0 à 50 ?
  • Ou des employés qui se défoncent pour ne pas avoir de pertes, et dont le bonus me coûte 8 à 10% (20% de ma marge brute qui est de 40-50%)
  • Gagnant-gagnant : l’employé va recevoir plus, et moi je sacrifie une partie du bénéfice possible car je sais qu’en réalité le projet sans perte n’existe pas.
  • Comme expliqué en 1), le taux d’activité réel d’un employé n’est jamais de 100% : l’interco existe dans toute ESN. Certaines ESN essayent de trouver des projets internes ou R&D mais en termes de rentabilité, il n’y a pas de solution. Quant aux pertes de production, elles sont inévitables, ne serait-ce qu’à cause des montées en compétence, formations ou créations de socles techniques, non facturables au client vu qu’on lui a vendu qu’on sait déjà tout faire avec une usine logicielle au top.
• L’agilisation des charges transverses : c’est une idée géniale. En imaginant qu’on arrive à diviser les 20% de charges entre 10% porté par des ressources en propre, et 10% par les développeurs, il est possible de réduire mes surplus ponctuels de services généraux : lors de démissions, baisses d’activités… cette réduction permet de gagner 1 à 2 % de marge nette sur l’année : c’est énorme vu la faible rentabilité globale.
• Dans les deux cas, je fais ressembler mon entreprise à une banque : je privatise les gains (bénéfices) et je rends publiques les pertes : projet en perte ==> perte de bonus ; interco ==> tu travailles dans des squads internes ==> pas de bonus; etc. Ça n’est possible que si je recrute des personnes assez expérimentées, mais pour ça pas de problème, les grosses ESN vont plus galérer à recruter que moi car leurs projets font moins rêver, du coup elles vont se taper la formation des juniors et je les récupérerai au bout de 3-4 années d’expérience.

Sur la rentabilité de l’entreprise :

S’il n’y avait pas de pertes de production, on voit bien que la rentabilité d’un ESN tutoierait les 20%. Ce n’est jamais le cas et ne sera jamais le cas, sinon avec déjà 10 personnes en mission, 1 chef, 1 commercial et un CA de 700k, le bénéfice de 140k ferait saliver une armée d’opportunistes.

Il n’empêche, comme écrit en introduction de ce chapitre, que le bénéfice va tomber chaque année dans la poche du patron, et dans une proportion bien plus élevée que les bonus.

En soi, la répartition est honnête : jusqu’à 15% de primes pour le salarié « libéré » par rapport à son salaire de base. En réalité comme vu en 1), le gain sera plutôt de 5% par rapport au salaire du marché. Et d’un autre côté, le patron va essayer de tirer 6 à 7% de rentabilité nette avec ses diverses optimisations (sans parler des éventuels loyers). Ça semble équitable.

Sauf que le patron d’une ESN de 50 personnes, n’a pas mis en capital un an de salaires de 50 personnes, contrairement à une entreprise industrielle ! Il reçoit en bénéfices 7% de la production de CHACUN des employés… ce qui représente au final 3,5 salaires, en plus de son salaire de patron. De quoi espérer un 15 000 euros net en bas de page chaque mois en comptant les dividendes.

Encore une fois, ce n’est pas choquant ni délirant par rapport au travail effectué, à la réflexion d’optimisation du travail qui est avouons-le maligne, au fait d’être joignable 24/24, etc. Mais il faut arrêter de se la jouer socialiste à ce niveau là : on est dans du bon vieux capitalisme. Donc pas de discours sur le partage, le bien-être des collaborateurs ou l’agilité.

Pour terminer, glissons d’ailleurs que je ne connais qu’une seule société qui fonctionne vraiment sur un mode coopératif : c’est Code Lutin. Les associés sont des codeurs (avec une assistante et un commercial) et y touchent le même salaire qui est la répartition entre tous, de tous les revenus. Le modèle est difficile, car les développeurs doivent porter une partie des fonctions transverses et commerciales de l’entreprise (je vois qu’ils ont désormais deux commerciaux).

Addendum : que faire alors ?

Tout ce discours a pu paraitre extrêmement pessimiste sur le secteur des ESN et sur toute initiative faite pourtant pour l’améliorer. Il n’en est rien, c’est juste de la lucidité après beaucoup d’années de pratique de cette jungle.

Comment améliorer la rémunération au mérite ? On pourrait calculer la marge sur l’ensemble d’un projet plutôt que par personne, afin de garder un esprit d’équipe.

On peut surtout dire que la notion même d’ESN n’apporte pas de valeur : les développeurs ont une valeur individuelle, comme chaque membre de l’entreprise. Ils auraient produit exactement la même valeur chez un concurrent : les ESN sont interchangeables.

Tout ce qu’elles proposent, c’est une agence d’intérim de luxe capable de mobiliser un certain nombre de personnes en un temps donné pour permettre à des clients de sous-traiter leurs développements informatiques. Tout le reste n’est que foutaises.

Les technologies évoluent tellement vite que la capitalisation au sein d’une entreprise est quasi nulle : ce n’est parce que mes collègues ont fait un projet sur « Flutter » l’an dernier que j’ai moi aussi progressé sur Flutter. Si l’entreprise signe un autre contrat en « Flutter » l’an prochain, certains développeurs seront partis, d’autres seront occupés sur d’autres projets, et la technologie aura elle-même bougé : parce que les ESN sont multi techno et multi secteur fonctionnels, je n’ai aucune garantie qu’il y ait véritablement un gain de compétence ou de productivité lors du projet suivant.

Si c’était le cas d’ailleurs, les taux de pertes finiraient par diminuer dans un centre de services qui réussit à garder ses bons développeurs… mais ce n’est pas le cas.

Un moindre mal serait donc d’avoir des ESN ultra spécialistes d’une seule niche :

• e-commerce
• Symfony
• dév métier bancaire
• Mise en place d’outils collaboratifs
• Etc…

Cette logique séduisante sur le papier, se heurte à la réalité :

• Du commerce : pour une ESN, hormis Paris (et encore vu la taille de la région parisienne, on ne peut pas intervenir partout), en se limitant à une niche, on risque d’avoir des commerciaux qui vadrouillent beaucoup, et remontent des besoins… qui ne sont pas traitables en interne. Il faudrait du flair en amont de la prospection, mais ce n’est pas possible car les clients ne sont pas assez matures sur leur besoin… la faute au fait de sous-traiter aux ESN depuis des lustres. La boucle est bouclée.
• De la dualité entre fonctionnel et technologie :
  • Soit la niche est technologique : lorsqu’un client remonte un besoin, une fois sur deux il a une contrainte technologique interne qui va lui faire préférer une à deux des grandes technologies et pas plus (Java, PHP, Microsoft, Javascript). Il va falloir accepter de perdre 50 à 80% des leads à cause de ce choix, qui est de surcroit dur à expliquer aux clients – mais permet par la suite d’avoir des leads mieux qualifiés
  • Soit la niche est fonctionnelle : c’est bien, vous allez pouvoir par exemple vous limiter à la prospection de l’industrie (vos offres pourraient être : extranet + IOT) ou de la banque (applicatifs métiers back). Par contre, il vous faudra avoir 23 développeurs connaissant 26 technologies, parce que déjà que votre terrain de jeu est réduit, si en plus vous dites à vos clients que vous ne faites pas de la CRM, du Mobile ou du big data, il ne va pas rester grand-chose…
• De la taille critique de rentabilité
  • Les deux raisons plus haut font qu’en dessous de 20 à 30 personnes sur une même technologie ou domaine fonctionnel, il est très difficile d’être rentable. De plus, avec une seule niche de 20 ou 30 personnes, un projet qui embarque ne serait-ce que 7 personnes, taille moyenne d’une équipe agile, vous met en risque sur votre rentabilité annuelle. Ce genre de sociétés de niche existent : on peut penser par exemple à KnpLabs sur Nantes, experts en Symfony. Mais ils sont vraiment experts : connaissent sur le bout des doigts le code du framework et font des formations jusqu’en Australie. Le CA de la douzaine d’employés n’a jamais dépassé le million d’euros, on voit bien que ce modèle n’arrive pas à grossir.

Voila pourquoi les ESN finissent par faire de tout et n’importe quoi… et du coup par ne plus avoir d’ADN et être des clones sans âme.

Que faire alors ? Il faudrait vraiment une prise de conscience des DSI de l’importance à relocaliser leur informatique en interne pour maitriser leurs données, leurs codes. Quitte à continuer de sous-traiter en TMA les vieilles applications ou celles qui sont dans des technologies « minoritaires » pour lesquelles ils ne peuvent pas avoir un développeur dans un coin. Cela les remettrait en plus dans une logique de stratégie : quelle est la vision à 10 ans de mes applicatifs ? pourquoi ? qu’est ce que cela me rapporte ? Qui sont mes cibles ? pourquoi telle technologie me convient ? etc. plutôt que d’empiler des bouts de code écrits par diverses sociétés sans aucune cohérence. L’ADEME est un exemple concret de cet empilage, au point que les périmètres de certaines applications se recoupent.

En 2001, un DSI pouvait se dire « je ne vais pas embaucher des développeurs web, c’est un effet de mode l’internet ». (c’était d’ailleurs, parenthèse, ce que m’avait soutenu le directeur de mon école d’ingénieurs à l’époque : qu’internet, c’était une mode). De nos jours, il a le droit de se dire la même chose pour l’IOT ou le big data (personnellement je pense que ces deux sujets auront une croissance lente comme toute ce qui touche à la supposée IA). Mais de grâce, qu’il embauche des informaticiens en interne pour ses applicatifs métier, web, mobile, et pour le cloud.

Si les DSI ne comprennent pas cette urgence, il faudra peut-être envisager un incitatif fiscal, par exemple une définition différente de la R&D faisant que seules les entreprises finales qui ont produit du code en interne (et sont donc dans un esprit « logiciel », de la construction) sont éligibles à un crédit d’impôt. Ce recentrage serait utile.

Ou bien taxer les contrats de sous-traitance informatique, que ce soit en AT ou au forfait, au nom de la lutte contre la précarité.

Il est évident que le jeu de téléphone arabe actuel de l’informatique est contre-productif : pour un seul projet « moyen », on se retrouve par exemple avec un sponsor, un CP MOE ou architecte client, un CP/expert MOA client, un commercial ESN, un DP ESN, un scrum master interne ESN, un proxy PO ESN, des développeurs ballotés entre tout cela. Quand allons-nous y mettre fin ?

Qu’une entreprise sous-traite 10 ou 20% de sa charge informatique, car il s’agit d’un débordement ou d’un gros projet dans une technologie utilisée nulle part ailleurs dans le SI. C’est légitime.

Quand, au niveau national, la part de marché des ESN atteint l’ordre de grandeur des 50%, nous savons intuitivement qu’il y a un problème. Je me suis d’ailleurs toujours demandé comment un DSI d’un grand groupe pouvait justifier de sous-traiter 50% de son activité vers des sociétés externes dont le TJM est de 450 euros, quand ses équipes à lui coûtent 350.

Quelle débauche d’énergie à écrire des cahiers des charges qui décrivent des tas de choses que les gens en interne savent ? A faire concourir 10 entreprises pour un seul projet, ce qui va fatalement faire jeter à la poubelle 9 travaux d’avant-vente ?

A faire des réversibilités, des contrats ? A faire travailler des commerciaux à plein temps pour « détecter » des opportunités qui n’existent que parce que les clients aiment jouer au jeu du chat et de la souris pour établir la confiance et garder des prix bas.

Et des assistantes qui vérifient des « CRA » à longueur de journée ? Franchement, qui peut penser que cette organisation est productive ? Personne. Pas à hauteur de 50% encore une fois. Alors oui, que le 0,8 ETP en Cobol dont j’ai besoin soit sous-traité, OK. Mais les plateaux de 30 personnes pour une banque, quelle est la logique, franchement, lorsque la TMA dure depuis 15 ans et a changé 3 fois de « centre de services » ?

Dans la décennie qui vient, bien que nos gouvernants les aient longtemps préservé, pantouflage et copinage oblige, les banques « traditionnelles » vont morfler. La raison est simple : depuis plusieurs décennies, elles refusent de s’approprier correctement leur informatique, et sont les premières utilisatrices de SSII.

Hélas, le 2e secteur le plus utilisateur de SSII est probablement le secteur public, et là, c’est nous les français qui payons les pots cassés à la fin. Soyez-sur, chers lecteurs, que la proximité politique entre des fondateurs de SSII (Capgemini es tu là ? et Sopra ? etc. sans compter à plus petite échelle, mon ancien patron qui affiche fièrement ses accointances avec LREM, et le précédent proche du PS qui d’un coup de fil à Nantes Métropole a pu faire construire un parking pour son entreprise) et nos hommes politiques n’est pas étrangère à cette folie de l’externalisation.