Test des panneaux solaires Sunology Play

Les panneaux solaires Sunology Play sont disponibles a prix public de 749 euros sur le site de Sunology, mais vous pouvez avoir 5% de réduction en suivant mon lien de parrainage : Parrainage Sunology -5%

Ensuite, les panneaux sont vraiment aussi faciles à installer que le dit la réclame de Sunology. C’est juste un peu lourd, car le panneau est livré sur une palette en bois et l’ensemble pèse 60kg. Au moins, pas de risque que ce soit abîmé !

Pour installer, un papier indique un QR Code qui redirige vers des vidéos d’installation au sol ou sur un mur.

C’est l’application Nedis Smart Life qui est recommandée, mais « Smart Life » tout court est en fait la même appli et marche très bien.

C’est assez étonnant de devoir cliquer sur la prise connectée puis sur « Statistiques » pour voir ces chiffres : car en fait, cela utilise la fonctionnalité « classique » d’une prise connectée, mais dans l’autre sens. La prise connectée sert normalement à compter la consommation de l’objet branché. Ainsi, j’ai brièvement testé la prise avec un téléphone branché dessus (via un chargeur) et la consommation apparaissait bien (en l’occurrence environ 12V et 80 mA, soit 1W au total)

La production et son optimisation

Le point que je n’ai pas lu sur les forums et qui me parait pourtant super important, c’est comment optimiser la production. Les Sunology Play ont 3 « crans » pour relever ou abaisser le panneau vers le sol, permettant de s’adapter à la saison pour maximiser la production de quelque chose comme 10-20%. Cependant, ce qui compte le plus, c’est l’emplacement. J’avais totalement sous-estimé l’influence des ombres. Un bout de maison ou d’arbre qui fait de l’ombre sur 20% du panneau, et c’est tout de suite 50% de puissance en moins ! Il semble y avoir quasiment un effet « cubique » de la surface ensoleillée sur le volume de production. Il est donc vital d’être en hauteur et à l’abri des ombres pendant le plus longtemps possible.

Un autre aspect que je n’avais pas lu, est l’aspect très progressif de la production d’électricité. Ainsi, lors d’une « arrivée » du soleil, le panneau va mettre 1 à plusieurs minutes pour arriver à son rendement maximum ! Là aussi, cela plaide pour que les ombres des arbres, maisons ou nuages ne viennent pas perturber l’ensoleillement trop souvent

Pourquoi ce kit ?

L’achat de ce kit a été le fruit d’une longue comparaison avec les 5-6 autres kits connus en France. Notamment, par rapport au très connu kit de Beem, tout est en faveur du Sunology :

  • Le prix (avec notre lien de parrainage) est près de 10% moins cher
  • Le kit Sunology est inclinable
  • Le montage est beaucoup plus rapide, tout est précablé
  • Le Sunology est compatible avec certaines batteries, afin de stocker de l’énergie excédentaire éventuelle
  • La puissance est de 400W et non 350 – et en conséquence le prix d’achat au watt est beaucoup plus faible !

Pour être 100% complet, l’application mobile du Beem est plus ludique (elle indique la production en consommations de téléviseurs ou d’ordis, elle compare la production avec la moyenne attendue par rapport à la ville de résidence,…) mais tout cela ne sont que des gadgets. Et le Beem peut avoir un intérêt pour des petits espaces, lorsque installer un gros panneau de 2m2 n’est pas possible, alors 4 petits panneaux c’est plus facile de disposer dans la configuration qu’on veut (en hauteur, en largeur ou en carré)

Autres kits

https://solatek.fr/1239-kit-solaire-autoconsommation-et-site-isole-avec-batteries-lithium-6000w-144kwh.html

https://allo.solar/kit-solaire-640w-230v-autoconsommation-aps.html

https://www.solaris-store.com/2205-kit-solaire-autonome-3000w-easysol.html

Batteries

Notre but est d’autoconsommer un maximum et de ne pas réinjecter d’électricité excédentaire sur la réseau. C’est un choix qui n’est pas forcément le plus intéressant financièrement, mais celui qui donne le plus d’autonomie.

Au niveau financier dans les grandes lignes, en 2022 le kwh acheté à EDF ou un autre fournisseur coute 0,20 euros. Le kwh solaire, revendu, nous est payé 0,10 environ. Cela signifie que l’ajout d’une batterie, par rapport à la réinjection, ne rapporte « que » 10 centimes du kwh. Cela rend le retour sur investissement long et aléatoire :

Admettons une batterie de 1kwh, remplie chaque jour et vidée chaque nuit. Si elle coûte 1000 euros et qu’elle permet de stocker (et donc ne pas perdre) 365 kwh par an, cela représente 36,5 euros.. trop peu pour imaginer être rentable !

Par contre par rapport à de l’énergie perdue, on obtient une rentabilité en 14 ans. D’où le fait que le prix de 1000 euros par kwh de batterie est un maximum à ne pas dépasser.

Les panneaux solaires en kit tels que les Sunology ne sont compatibles QUE avec les batteries AC (petites batteries type Bluetti ou Ecoflow) mais pas avec les gros « walls » en courant continu DC, comme les Tesla Wall ou LG Chem RESU10. Solawrwatt My Reserver ne sera lancé en France qu’en 2023 donc à voir si ce sera compatible

En fait par nature et si j’ai bien compris, comme les kits doivent pour ne pas nécessiter de déclaration à EDF, injecter leur électricité via une prise, ils DOIVENT avoir converti l’électricité en AC (qui est le type d’électricité qui circule sur un réseau domestique). Et donc ils ne PEUVENT PAS injecter

Donc à tester : Bluetti à environ 1040 € du kwh en achetant une « base » AC300 + 2 extensions « B300 » pour un total de 6,144kwh : permet une entrée solaire jusque 2400w, c’est bien !

Le Ecoflow ne peut être chargé que par un maximum de 800w solaire : c’est un peu nul

Traqueur solaire

Juste pour le signaler : une idée « lumineuse » est d’avoir un panneau solaire « tournesol » qui suit le soleil au cours de la journée pour optimiser la production. On gagne alors beaucoup en début et fin de journée, et au total quasiment 40% de production. Le problème, c’est que ces « traqueurs solaires » sont hors de prix. La « Smartflower pop » avait une puissance crète de 2,5kWhc et une production espérée de 4000 kwh par an. Mais pour un prix délirant de l’ordre de 17 000 euros, le prix au « kwh annuel » était 4X supérieur à la normale. Du délire !

Une autre solution est le traqueur solaire sous forme de grand « pic » motorisé. A 1800 euros, pour supporter 2 panneaux solaires, cependant, ce n’est pas rentable : cela fait plus que doubler le prix du panneau, pour une augmentation de 40% de production…

En fait, ce genre d’équipement devient rentable à très haute échelle, pour des fermes solaires où la motorisation de dizaines ou centaines de panneaux devient rentable.

Recevoir des SMS sur un autre numéro

Si vous avez besoin de recevoir des SMS sur un autre numéro que le votre (pour des raisons de discrétion, ou une autre raison moins avouable), il y a deux solutions principales :

  1. Louer un numéro de téléphone : tous les messages et/ou appels envoyés vers ce numéro sont reroutés vers le votre, par exemple via Ringover. Le prix est de quelques euros par mois.
  2. Utiliser un service gratuit qui met à disposition des « numéros ouverts ». Ouverts à tous, ces numéros sont visibles sur des sites internet : n’importe qui peut les déclarer pour une ouverture de compte Apple, Google, Microsoft ou autre demandant obligatoirement une vérification par SMS. Les messages reçus sont visibles par tout le monde sur internet : c’est un risque, mais comme en général les messages ne disent pas qui a fait la demande, et ne permettent que de rentrer un code de vérification, sans mention du mail ou du compte demandeur, c’est finalement assez sûr. Quelques exemples : https://trobweb.com/fr/2021/12/fake-number-sites-to-receive-messages.html, http://receive-sms-online.info/

Mails chiffrés dans la pratique

Ce qu’il faut faire attention avec des emails chiffrés :

  • Il n’est pas possible DE FAÇON SIMPLE (sauf à recevoir un amas de lettre chiffrés et à le déchiffrer à la main) d’échanger des emails chiffrés entre deux systèmes concurrents
  • Par exemple, entre Tutanota et Protonmail : les mails seront par défaut envoyés non chiffrés (sauf si demandé et déchiffrage à la main) MAIS on peut aussi utiliser la fonctionnalité de « mails avec mot de passe » : le destinataire reçoit alors un email (non chiffré) lui donnant un lien pour ouvrir le mail (chiffré et lu sur le serveur du fournisseur). Il est protégé par mot de passe, ce mot de passe est à donner par un autre moyen (téléphone, Télégram, etc)

==> il ressort de ce premier point que pour qu’un pourcentage élevé de ses mails soient vraiment chiffrés, il faut soit utiliser un des ténors du secteurs, soit (ou/et) un fournisseur qui permet d’envoyer des emails protégés par mot de passe.

L’algorithme

Par définition, on ne peut pas faire « mot de passe oublié » avec un fournisseurs d’email chiffré. Et même changer le mot de passe, par définition, a un effet sur le chiffrement. En effet, le mot de passe est « mélangé » avec la clé privée, puis le tout est stocké sur le serveur du fournisseur, pour encoder les emails. Là, l’algorithme utilisé est donc important : il ne sert à rien d’avoir un système de chiffrement s’il est facilement crackable. Protonmail utilise bcypt + AES-256.

La juridiction

Autre point important : il faut vérifier à la loi de quel pays est soumise la plateforme : en effet, la CIA met son nez partout, et la plupart sinon tous les pays du monde, essayent d’enregistrer tout ce qui passe sur leur territoire. Surtout, des pays comme les USA ont des lois de « bâillonnement » qui permettent d’obliger un prestataire à mettre une porte dérobée dans leur plateforme pour récupérer les données de quelqu’un.

Exemple précis : Tutanota a été obligé par un jugement d’un tribunal allemand, à mettre un « if » dans le code source de son serveur, pour aller copier les emails non chiffrés qu’un de ses utilisateurs échangeait (pour harceler des gens). Mais au moins, il n’ a pas été bâillonné, et a pu le dire. Cela peut aussi arriver sur le site web : rien ne dit qu’un javascript sur le site ou l’appli mobile, ne va pas copier la version « déchiffrée » du mail ! car oui, tous les fournisseurs se vantent que ni eux, ni personne ne peut déchiffrer un email stocké sur leurs serveurs (enfin, ce n’est pas entièrement vrai : disons juste que le brute-force sera très long). Mais si le client qui lit les emails n’est pas open source, alors rien ne prouve que ce genre de système de copie n’est pas en place…. bien sûr, si cela existait de manière générale, les hackers qui testent ces messageries l’auraient vu (on verrait des paquets de données qui « renverraient » le mail déchiffré vers un autre serveur). Mais cela ne veut pas dire que cela n’arrive pas ponctuellement.

La centralisation

Qui dit serveur, dit risque de centralisation. A quoi sert de payer un fournisseur si un pays, ou groupe de pays, peut blacklister les serveurs d’un fournisseur ? Ce genre de menaces plane au-dessus de la tête des gros acteurs, surtout s’ils venaient à ne pas coopérer pleinement avec la police. Seul un système d’emails en peer2peer est résistant à la censure

L’email en lui-même n’est pas secure

Les emails n’ont pas été prévus pour être sécurisés. Ils ont l’avantage d’être interopérables. Mais ils exposent des métadonnées, des titres, etcetera. Ils n’ont pas le « forward secrecy » : la même clé privée est utilisée pour signer tous les messages : si cette clé venait à être dérobée (ou crackée), l’ensemble des anciens messages sont alors déchiffrables. Ce n’est pas le cas avec une messagerie instantanée, qui définit une clé à chaque session. La messagerie instantanée peut utiliser des protocoles distribués ou peer2peer comme Briar, Jami, Element (ou à défaut, Signal qui n’est pas peer2peer).

A noter que Jami est une appli peer2peer avec des fonctionnalités « classiques » (tchat, vidéo) tandis que Briar (codé en Java) ne fonctionne que via Tor, ou connexion directe (même Wifi / Bluetooth) et est donc destiné à une « élite » d’activistes. De par sa nature distribuée avec des « copies » de blog (donc incensurable), Briar se rapproche plus d’un Freenet.

Element quant à lui est un système de tchat « privé » à héberger soi-même, avec possibilité de parler avec les autres utilisateurs du système qui sont sur un autre serveur. Une sorte de « IRC moderne à héberger facilement » en fait, ou de « Signal décentralisé mais avec beaucoup moins d’utilisateur et qui ne remplace pas le SMS ».

Protonmail a beaucoup été accusé.

Est-ce parce que ses concurrents sont jaloux de sa réussite ? Ou est-ce parce que c’est vrai ? Dans tous les cas, Protonmail a plusieurs fois été accusé d’être un produit de la NSA. Notamment, parce qu’il utilise bizarrement un certificat sur un site .onion (ce qui est inutile et redirige vers le .com). Ou parce que son chiffrement « de bout en bout » peut-être compromis en envoyant un script dans le navigateur de l’utilisateur (comme Tutanota) et qu’il ne chiffre pas les métadonnées. Or les métadonnées (qui parle à qui, quand, sous quel titre) c’est ce que la NSA préfère. Et d’autres sites le disent, Protonmail stocke la clé chiffrée et peut par un tour de passe-passe détourner un email vers un tiers (via un JS corrompu).

Quand on sait que la NSA peut espionner (via les opérateurs + des hacks de déchiffrements partiels du SSL) tout le trafic mondial et le stocker pendant quelques jours (et y accéder via XKeyscore), on sait que la messagerie chiffrée est une épine dans leur pied.. il faut donc se méfier

Lavabit

Lavabit, le fournisseur d’email qui d’après les rumeurs s’est sabordé en 2013 afin de ne pas divulguer des informations concernant les emails d’Edward Snowden, est revenu en ligne. Pour 30$ par an, il promet de sécuriser des clients mail, et aussi d’avoir son propre serveur de mail. Je n’ai pas creusé, mais cela semble plus sûr qu’un système centralisé comme Protonmail

Posteo

Les alternatives à Protonmail existent. Est souvent recommandé Posteo, qui a l’air sérieux. Il y a également « That One privacy Guy » qui a fait un fichier Excel récapitulatif.

Avec 6 notes « vertes » sur 8, Posteo est devant Neomailbox et Protonmail à 5. Cela peut-être une bonne alternative., mais il faut noter que Posteo ne chiffre pas les métadonnées. Cependant, Posteo, contrairement à Protonmail, ne stocke PAS votre clé privée sur internet (Protonmail l’encode, mais tout de même il en stocke une copie chiffrée). Et de plus, Posteo permet d’envoyer un email chiffré à n’importe quel correspondant qui utilise le standard OpenPGP : au contraire de Protonmail qui par défaut, ne chiffre que vers les adresses Protonmail, ou alors vous devez « savoir » si votre correspondant supporte le chiffrement…

A l’inverse, Protonmail a son système d’envoi de mail « chiffré par mot de passe » vers un correspondant dont la boite ne supporte pas le chiffrement : Posteo n’a pas cela.

Mais alors que Protonmail et Posteo ont tous les deux le code de leur webmail en open source, Protonmail propose des applis mobile « closed ».. alors que Posteo lui n’offre pas d’appli mobile : on accède via un client et le protocole POP3 ou IMAP.

Reste à étudier les solutions non centralisées

Il en existe une dizaine de connus, relatés sur ce site.

Le premier de la liste, Countermail, est un fournisseur d’emails PGP (comme Posteo) mais avec la particularité d’être « diskless » sur son serveur : ce n’est PAS décentralisé ==> pas d’intérêt.

Criptext : est en fait une surcouche à Signal ; il permet d’échanger des mails chiffrés uniquement entre utilisateur de Criptext, mais pas vers les adresses de type Protonmail ou Posteo : c’est très dommage et rend le système, dans la pratique, inutile.

Cryptamail : est basé sur la blockchain « NXT » : mais l’idée de stocker des emails sur une blockchain publique parait loufoque.. c’est en beta depuis 2014 et leur site web n’est même pas en HTTPS.. pas très sérieux..

Les autres services cités dans l’article sont tout aussi bidons ou inutiles, ou sont les plus connus (Posteo, Protonmail, Tutanota). Donc la conclusion après ces recherches est hélas : il n’existe pas de service email distribué. Cela n’existe pas. Cela peut aussi s’expliquer par des contraintes techniques : envoyer un email suppose de configurer des serveurs qui reçoivent les mails. Cela se fait via des entrées « MX » dans une configuration d’un domaine : il est donc difficile d’imaginer que cela se passe sans une centralisation..

Ajout 2022 : chiffrer via un plugin

Il y a une autre solution, qui est d’utiliser un protocole du genre Autocrypt. Ce protocole propose de « détecter » après un premier échange, si votre correspondant support le chiffrement, et si oui de l’activer. Hélas, il est compatible avec très peu de systèmes de mails, notamment k9mail.app, un client de messagerie. L’idée est que, en gros, vous avez un gmail, mais y transitent uniquement des mails chiffrés, que l’appli K9 déchiffre sur votre téléphone.

Problème, aucun système n’est complet. K9 ne fonctionne que sur Android (donc impossible de lire ses mails sur C), les plugins Thunderbird ne marchent eux que sur PC, d’autres sont en ligne de commande, letterbox ne marche que sur IOS,.. Eventuellement, il y a « MailPile », un logiciel qui peut être installé sur un serveur cloud (ou sur un PC personnel ou n’importe quel ordinateur relié à internet) et qui est un client mail, qui ajoute la possibilité d’autocrypt. Mais, outre la difficulté de devoir installer sur un serveur cloud si on veut un accès de partout, il ne fonctionne que dans un navigateur. Au revoir, appli d’email. Eventuellement, on peut le coupler à un système pour avoir son propre serveur mail, comme https://mailinabox.email/ ou https://www.iredmail.org/ ou encore via Yunohost

Expatriation aux USA

L’expatriation devient difficile car les entreprises envoient de moins en moins d’expatriés mais ça se tente.


Pour être honnête, il ne faut pas se limiter aux types de visa car chaque entreprise a ses « visa » fétiches (H1, E2, L1) et ce sont leur RH qui gèrent.
A savoir:
– le H1 permet de bouger partout
– le L1 bloque sur l entreprise
– le E2 bloque sur les entreprises qui ont un capital de + de 50% d’une nationalité donnée. Par exemple pour nous français, avec un visa E2 on peut changer vers une autre boite qui a plus de 50% de son capital détenu par des français (cf BNPParibas dont c’est le visa préféré).

Sinon il reste l’ONU, UNICEF, ambassades, consulats … à explorer également qui ont leurs visa diplomatiques et des boulots intéressants

Email sécurisé

La volonté de censure de l’état « capitalo-communiste » à la Chinoise qui s’étend sur la planète entière depuis la soi-disant crise de la grippe Covid, pousse forcément à vouloir préserver un minimum de liberté.

Les derniers mois ont montré que tout peut basculer très vite, sous n’importe quel prétexte : l’état d’urgence permanent donne les pleins pouvoirs et permet à l’état de s’arroger le droit de mettre n’importe qui en détention pour n »importe quelle raison : la seule chose qui les en empêche est d’une part le nombre de dissidents encore trop élevé (donc on tape uniquement sur les plus célèbres, via les accords de censure avec Facebook, Twitter et consorts), et d’autre part la nullité technologique du gouvernement français.

Ils ne sont déjà pas capables d’utiliser correctement leurs moteurs de recherche d’espionnage des conversations privées pour traquer quelques milliers de terroristes, alors imaginez comment ils pourraient traquer des millions de gens.. Pour le moment.

Cependant, mieux vaut prévenir que guérir. Des services comme Gmail et TOUS les services grands public de taille suffisante, sont susceptibles d’ajouter une backdoor, sur ordre du gouvernement, qui renvoie tous vos messages. En fait, Gmail (et les autres) a même automatisé la remontée de ces informations sur demande : Snowden l’a montré dans ses leaks, qui pourtant datent d’il y a un paquet d’années.

La première réaction est de se dire : moi je ne suis pas fou, je ne veux pas autoriser Gmail à lire tous mes emails (car oui c’est ce qui se passe et leur permet d’améliorer le profil qu’ils ont sur vous et compte environ500 champs.. enfin je ne sais plus si c’est celui de Google ou de Facebook qui a 500 champs, mais bon vous avez l’idée). Mais il n’existe quasiment plus aucun « petit » service d’email, qui soit gratuit et au service correct. Yahoo, Hotmail, GMX, Free, SFR.. tous ceux là sont des gros.

Les geeks peuvent imaginer hoster un serveur mail eux-mêmes via des outils opensource de type Roundcube. Mais c’est un énorme travail d’installer une pile complète d’antivirus (type clamavis), de configuration de MX, de forwards, de règles de sécurité.. tout ça pour à la fin finir vite fait en spam car des providers peu scrupuleux de type Free ont la gachette du bannissement très rapide (j’ai eu beaucoup de problèmes avec eux lorsque je faisais du « mass mailing » et je les hais pour ça).

Chiffré ?

Alors, il reste la solution de l’email chiffré. Il y a quelques années, un ancien collègue était tout fier d’exhiber son adresse protonmail, c’était la première fois que j’en entendais parler. Ca m’a plu. Et puis en creusant le sujet pour cet article, je me suis rendu compte que ce n’est pas la panacée non plus: par définition, même chiffrés, un serveur mail converse une copie de tous vos mails. On raconte que la NSA garde des emails chiffrés quelques années car régulièrement, les progrès des 5 années suivantes permettaient de les chiffrer. C’est moins vrai maintenant car avec le chiffrement 2048 bits et le matériel qui progresse peu, les chiffrement « durent » plus longtemps. Mais rien n’est éternel. Bon, 5 ans après, pour un utilisateur normal, ça suffit largement pour éviter d’être « tracé » en s’enfuyant d’un pays par exemple. Mais. Protonmail n’a pas que des amis : il ne chiffre que les contenus, pas les titres des emails. Or la NSA s’intéresse presque plus à « avec qui vous échangez des emails, sur quel titre, à quelle heure » que au contenu (qu’ils ont de toute façon bien du mal à garder plus de quelques jours pour le monde entier, car cela génère trop de données. Ils peuvent archiver des contenus de mail, mais uniquement pour les dissidents sur liste noire). Bref, à la fin, la NSA en saura quasiment autant sur vous, car n’oubliez pas qu’ils font des copie du trafic directement depuis les câbles transatlantiques.

Tutanota ?

Protonmail a l’avantage d’être Suisse, donc en dehors de l’UE, dans un pays réputé pour son respect de la vie privée. Mais lien au-dessus jette des doutes. Tutanota lui, chiffre les titres, ainsi que les contacts, et n’utilise jamais de captcha Google. Et leurs clients sont entièrement open source et la partie mobile est publiée sur F-Droid, gage de non espionnage. Cependant l’actualité vient de nous rappeler que même eux, étant situés en Allemagne, doivent obéir aux juges et installer des backdoors pour fournir les messages non chiffrés reçus par leurs utilisateurs, avant le stockage chiffré sur leurs serveurs. Certes le jugement n’est que sur un cas, mais en ces temps incertains cela peut vite bouger.. et cela rappelle que les homologues américains, avec les « gag orders », peuvent avoir le même genre d’ordre du gouvernement et EN PLUS avoir l’interdiction d’en parler.

Tutanota a pris publiquement la défense du chiffrement contre les attaques répétées, notamment du gouvernement américain, qui souhaite obliger les fournisseurs de chiffrement à fournir une « master key » au gouvernement.

L’actualité nous montre que même Tutanota doit intégrer une backdoor. Donc que faire ?

Chiffrement local ?

La solution la plus sécure reste évidemment de chiffrer soi-même les messages, avec une clé partagée avec le destinataire, ou un système clé publique / clé privée. Mais cela nécessite un outil bien conçu afin que ce ne soit pas trop complexe, et surtout que vos correspondants l’utilisent !

Passlok peut-être une bonne solution pour cela, mais je n’ai pas eu le temps d’approfondir l’usage exact et si c’est pratique pour les correspondantes. Au moins, on évite le stockage sur un serveur. Cryptext propose cela aussi (avec un fonctionnement similaire à Signal) mais uniquement entre utilisateurs Cryptext, ce qui est très léger..

Tagués avec :

Applications pour un téléphone pas espionné par Google

Clavier : seuls trois claviers de bonne qualité n’envoient pas de donnés en ligne (que ce soit les textes tapés, ou des informations d’usage pour de la pub). Malgré les « privacy policies » diverses et variées, les autres le font. Donc il reste :

  • AOSP keyboard
  • Anysoft keyboard
  • Hackerkeyboard

Certains utilisent le clavier Google avec le firewall « afwall » mais je le recommande pas : les données restent stockées en local pour envoi ultérieur, ce qui permet une lecture ultérieure si le téléphone est volé, saisi par la police, piraté par un ver local, etc.

Calendrier : Offline Calendar (sur F-droid) permet de se passer des calendriers intégrés à Gmail et de stocker son agenda hors ligne sur le téléphone.

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 2e 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.

Top
%d blogueurs aiment cette page :