J'ai écrit dans mon précédent article que j'allais écrire au sujet de l'open-source. On est Dimanche, il fait beau, c'est le moment idéal !

Parlons donc du lien entre l'open-source et l'économie de l'informatique - en France avant tout.

Il y a quelques années, en mission chez Adeo, j'ai assisté à une très intéressante présentation d'un des membres du board de la fondation Apache sur le rôle de cette fondation.

riduidel Nicolas Delsaux 29 juin 2018 à 11:24:14 This keynote by Dirk-Willem van Gulik is incredible ! Apache Foundation: Organization of large scale Open Source projects at ADEO Dev Summit https://t.co/p0MOwQJdjZ #AdeoDevSummit. Completes very nicely the one by @bdelacretaz at #devoxxfr

Le présentateur y expliquait que le rôle de la fondation Apache était avant tout d'offrir une couche d'isolation contractuelle aux développeurs open-source. Et il y expliquait aussi comment l fondation a été créée. je vais commencer par ça, parce que c'est assez typique.

A ce sujet, l'article de la wikipedia est aussi parfaitement exact qu'inexact. Ce qu'a expliqué Dirk-Willem, c'est que les scientifiques qui ont écrit le serveur Apache, sur leur temps libre parce que leur employeur n'avait pas les moyens d'en acheter un, se sont rendus compte qu'en cas de poursuite judiciaire, ils étaient pénalement responsables. Il leur fallait donc une structure juridique les isolant des endroits où ce logiciel serait déployé, ce qui est le rôle des fondations open-sources.

Ce que je trouve fou dans cette histoire, c'est que ces gens ont travaillé pour leur employeur en plus, et que, pour schématiser, leur employeur s'est contenté de leur signaler qu'il pourrait se retourner contre eux. Bon, leur employeur, ou plutôt les parties de l'employeur qui voient dans les employés de petits rouages bien efficaces. Pour le dire autrement ... les comptables. Les mêmes qui voient depuis toujours l'informatique comme un coût.

Et on pourrait croire que l'attrait du prix nul était suffisant pour convaincre les entreprises ... En réalité, ça n'a pas été aussi simple : pendant longtemps, incitées par des fournisseurs à la moralité élastique (comme Microsoft ou Oracle), les entreprises refusaient d'utiliser de l'open-source, à cause de la viralité de la GPL, par exemple, ou d'autres considérations à base de "je ne vais pas laisser s'exécuter du code qui n'est pas audité" (croquignolet, quand on entend les récits de guerre de certains vieux développeurs ayant installé des backdoors plus ou moins nocives). Mais très vite, l'avantage du code gratuit, facile à intégrer (surtout dans des langages disposant d'un écosystème riche ainsi que de moyens commodes d'y accéder, comme le Java) a vaincu ces réticences, et on s'est retrouvé avec de plus en plus de code open-source maintenu par des équipes plus ou moins payées mis au service de ... toute l'industrie de l'informatique du monde.

Résultat, aujourd'hui, vous écrivez tranquillement votre code Spring en rajoutant des dépendances (comme Failsafe ou Retrofit) sans vous soucier des gens qui ont développé ces dépendances. C'est bien ? Pour avoir utilisé moi-même ces dépendances, et avoir codé un peu d'open-source, c'est surtout bon ... pour le comptable de mon client, qui réduit le coût de développement du logiciel à mon tarif horaire.

Et franchement, ça fait du développement logiciel l'une des activités les moins coûteuses au monde. En fait, il n'y a que les métiers de service faiblement qualifiés qui coûteront moins cher : organiser une fête, faire livrer du matériel ... Toutes les activités d'investissement (comme l'est le développement logiciel) coûtent infiniment plus cher.

Et si vous voulez l'une des raisons pour lesquelles les éditeurs logiciels souffrent, c'est précisément ça : comme le logiciel est un coût, et que l'open-source ne vaut rien, chaque produit payant se retrouve concurrencé par une alternative open-source moins performante, mais aussi beaucoup moins chère (je le sais, je joue à Mindustry plutôt qu'à factorio).

A ce sujet, une petite parenthèse : ce qui arrive aujourd'hui à Elastic (qui se fait dévorer par Amazon) ou à Docker (qui se fait étouffer par Google - entre autres) est normal : un éditeur logiciel ne peut pas lancer un produit open-source s'en s'attendre à ce que des gens plus à l'aise en stratégie produit, et disposant de moyens supérieurs, ne vienne dévorer son marché par tous les moyens possibles. C'est mal. Mais c'est une partie de la nature humaine.

Attention, je n'écris pas ici que l'open-source est mal en soi. Au contraire, je crois vraiment que c'est l'une des transformations les plus enthousiasmantes qu'ait apporté la révolution numérique. J'écris plutôt que les entreprises consommatrices d'informatique y voient un moyen commode de réduire ce qui n'est vu que comme un coût.

Et c'est peut-être la raison pour laquelle les initiatives de financement de l'open-source ressemblent à ce point aux cagnottes qu'organisent les américains pour pallier leur système de santé défaillant ... Dans les deux cas, c'est une forme de charité douteuse, qui n'existe que parce que les gens qui ont l'argent ont trouvé des façons intelligentes de ne pas payer pour le service rendu.

Cela dit, il y a quelque chose de profondément positif à tout ça. Je crois que cette chute des coûts est à l'origine de la transformation numérique que subissent les entreprises françaises : comme le développement de nouveaux logiciels ne coûte pas grand chose, les entreprises en développent des tonnes, et financent une partie du développement des solutions open-source, tout en s'enfonçant dans une informatisation de plus en plus poussée. Ca ne veut malheureusement pas dire que les entreprises deviennent plus efficaces (et franchement, j'ai des doutes). En revanche, ça veut dire que le travail d'informaticien va devenir de plus en plus central, ce qui changera sans aucun doute les structures de pouvoir.

J'ai écrit il y a peu un petit truc sur La structure du marché informatique en France. Si vous ne l'avez pas lu, je pense que ça le mérite. Et maintenant que vous l'avez lu, on va passer à autre chose. Et comme la question est en titre, je ne me répète pas.

Où travaillent les développeurs en France ?

Ou plutôt, qui sont les employeurs en France ? Je n'ai pas de chiffres précis ... Mais j'ai quand même une approximation. Enfin, ZDNet dispose d'une approximation que j'ai même traduit en image

Comme vous le voyez, si vous voulez travailler ailleurs que dans une ESN, ça va être dur.

Mais d'où ça vient ?

C'est assez simple structurellement, et franchement, vous vous en doutez déjà : dans un marché dominé par des entreprises développant des logiciels sur-mesure, les éditeurs de logiciels, qui produisent du logiciel "standard" et moins adaptable sont désavantagés sur le plan de l'adaptation au besoin, mais évidement intéressant financièrement.

Cependant, et c'est la partie délicate, une partie significative du logiciel développé en France est cachée : les entreprises développent beaucoup plus de logiciels correspondant à leurs besoins internes que de logiciels publiquement exposés. Et ces logiciels internes sont, la plupart du temps, développés sur mesure. Sans doute parce que, dans une rhétorique du sur-mesure très "la France, le pays du luxe", chaque dirigeant est incité à penser que son entreprise est et doit être absolument spécifique.

Autrement dit, le marché incite les clients à consommer (c'est un poil le concept de société de consommation). Et qui dit incitation à consommer, dit aussi produit de qualité médiocre, mais comme je l'ai écrit, ça n'est pas l'objectif ...

Cependant, si la qualité n'intéresse pas le client ni le vendeur, ça intéresse quand même un peu plus le consultant qui va honorer la promesse vendue.

Et il y a pire

Est-ce qu'informaticien est un job qui fait rêver ? D'après le parisien .. pas vraiment (oui, j'ai parfois des sources de qualité) ou plutôt ça n'est pas un métier dans la liste de ceux qui font rêver. En revanche, même l'état le dit, c'est un métier qui recrute. Et, pire encore, on retrouve le "métier" d'informaticien par exemple dans cette liste des dix métiers que les français ne veulent pas faire. Il s'agit donc d'un métier pour lequel on cherche des compétences, et qui ne fait pas rêver, ok, la démonstration est faite. Mais ça implique quoi ?

Ca implique d'abord que les gens sensibles à l'image qu'ils projettent ne feront pas ce métier à cause du stigmate social (c'est rare, mais ça arrive). Ca implique aussi que, puisqu'on ne trouve pas assez de gens motivés pour faire ce métier, il s'agit aussi d'une voie de reclassement. On trouve donc régulièrement (et j'ai eu également des collègues très sympathiques qui étaient dans ce cas) des gens en reconversion, qui n'ont aucune appétence particulière pour ce métier. Ceux qui vont passer leur pause à vous parler du dernier match de foot ou de la dernière série à la mode. Cette population a un point commun avec ceux qui, dirigés par leur ambition (ou leurs enseignants en formation), souhaitent avant tout devenir des chefs, parce qu'être chef, c'est cool.

Ca crée donc une population de développeurs peu sensibles à la qualité des logiciels produits, et plus à la satisfaction de leur hiérarchie. Ca n'est pas une mauvaise chose en soi, mais ça n'aide pas à la satisfaction du travail bien fait.

Mais alors, on fait quoi ?

C'est la question que m'a posé un collègue cette semaine. Globalement, en tant que développeur, vous avez le choix entre

• Travailler chez un client final, auquel cas votre travail est avant tout politique. Ca n'est pas une mauvaise chose, pour peu que vous aimiez l'idée de convaincre les gens du bien-fondé de vos plans stratégiques, et que vous ne vous intéressiez que modérément à la réalisation technique de ces plans. Vous aurez par ailleurs accès à des locaux spacieux, à un salaire plutôt élevé et aux moyens d'une entreprise établie, mais chez laquelle l'informatique n'est qu'un moyen (puisque vous vous replacez dans le contexte historique de développement de l'informatique : un moyen d'optimiser les coûts de l'entreprise pour faciliter son développement).
• Travailler dans une ESN, où vous serez confrontés à des projets variés, dans des contextes variés, mais où vous ne choisirez pas le contexte métier. Ca veut dire aussi que vous serez envoyé en mission à peu près n'importe où, et traité par vos interlocuteurs quotidiens (les clients de votre employeur) comme un fournisseur.
• Travailler chez un éditeur de logiciel, où le contexte ne changera pas (ce qui ne veut pas dire que vous aimerez ce contexte), et où la réussite de l'entreprise dépendra directement de la qualité de ce que vous produisez. Évidement, vous serez un peu moins bien payé, sans doute à cause des difficultés existentielles des éditeurs. Et votre "aventure" a des risques de mal se terminer.

Ecrit comme ça, aucun choix n'est bon. Mais en vérité, aucun n'est non plus vraiment mauvais ... Sauf bien sûr si vous croyez à la fin du capitalisme ... Mais on en reparlera.

Pour ma part, j'aime continuer à coder ... mais je me rends compte que je suis de moins en moins intéressé par le développement dans le contexte d'entreprise. Et comme j'ai une expérience significative, je peux aider mes clients en fournissant d'autres services : de l'architecture, de l'accompagnement des développeurs (et des équipes). Et je pense que pour les développeurs un peu passionnés, les opportunités d'évoluer dans des environnements favorables (autrement dit où on ne se fait pas trop emmerder) sont en ce moment innombrables.

Cela dit, ce serait bien que les choses changent. Mais ce sujet mérite lui aussi un article complet (et je suis sûr qu'il y aura un lien avec le dernier épisode des castcodeurs)

Cet article correspond à un sujet qui me tient de plus en plus à coeur, qui explique beaucoup de choses, (et dont j'ai déja parlé à mes collègues) mais dont j'entends peu parler.

L'histoire rêvée de l'informatique

Quand on parle de l'histoire de l'informatique, les premières choses auxquelles les développeurs pensent (et pas qu'eux, encore que je ne suis pas sûr que Catherine Dufour - la trop peu célèbre autrice d'une biographie d'Ada Lovelace - soit disqualifiée comme informaticienne) est Ada Lovelace, la déesse tutélaire, Alan Turing et son test ou encore Von Neumann et ses machines. Ces éléments sont certes intéressants, mais ils font partie d'une histoire fantasmée, d'une espèce de récit national. Et si, pour de trop peu nombreuses personnes, l'histoire est une science, pour le plus grand nombre, l'histoire est un moyen de définir son identité.

Et cette définition des informaticiens comme des héros incompris colle avec la démographie, à défaut de coller avec la réalité.

Or, comme je l'écrivais, l'histoire est souvent un moyen de définir son identité. Si au lieu de regarder du côté des développeurs, on regarde du côté des entreprises, le site du CIGREF présente une histoire de l'informatique vue par le spectre des entreprises particulièrement intéressante, et que je me permets de me recopier ici.

Si on regarde cette préhistoire de l'informatique, on constate que Bull, IBM existent avant les travaux de Turing. Et ça n'est pas un hasard, parce que ces entreprises fournissent alors des machines d'automatisation et de comptabilité. Et la comptabilité, avant tout, c'est une source de coûts : avant ces machines, il faut des calculateurs, souvent humains, par dizaines, voire plus (c'est d'ailleurs ce qui s'est passé à Los Alamos, qui rassemblait pour le projet Manhattan tous les étudiants américains sachant compter). Et comme souvent, la guerre sera un terrible accélérateur qui permettra à ces entreprises de faire le virage de l'électronique, puis de l'informatique : dès les années 70, les ordinateurs nécessitent des systèmes d'exploitation, des langages de programmation plus performants.

Mais qui dirige ces innovations ? Les laboratoires de recherche ou les grandes entreprises ? Mon point de vue est évident : l'informatique est apparue comme un outil d'optimisation des coûts, en effectuant les calculs plus vite (plus correctement, et pour moins cher) que des humains. Et c'est à mon avis en accord avec le fait que, pendant longtemps, l'informatique s'est cantonnée dans les entreprises au back-office ... Parce que l'informatique a été vue, historiquement, comme un outil de comptable : un moyen commode de connaître la santé d'une entreprise sans pour autant déployer des armées de comptables dans tous les services.

Et cette "histoire alternative" n'inclut évidement pas certains événements récents, qui font partie de la révolution industrielle de l'informatique : l'explosion de l'ordinateur individuel, la transformation du monde par internet, la première bulle des startups de l'an 2000. Pourtant, je pense que ces différents éléments restent explicables dans ce cadre.

Mais en France ?

Si cette vision est à peu près globale jusqu'en l'an 2000, l'explosion d'internet précipite toutefois une bascule géopolitique : les états-unis prennent nettement le pouvoir dans ce domaine, reconnu dès cette époque comme essentiel (peut-être que les liens entre les start-ups de l'époque et les agences de renseignement ont aidé). Alors qu'en France ... il ne se passe rien.

Et c'est bien normal.

Un jour, je détaillerai pourquoi la France n'est plus un pays techno-scientifique (n'hésitez pas à me le demander en commentaires). Disons pour l'instant que les patrons d'entreprise sont plus souvent issus d'écoles de commerce que d'écoles d'ingénieurs, et qu'il en va de même des responsables politiques.

Toujours est-il qu'en France, une révolution technologique, ça n'intéresse pas grand monde, sans doute parce qu'il n'y a pas de leader technologique mondial en France. De ce fait, l'informatique, qui est devenue aux états-unis un moteur de croissance, reste en France un centre de coût. C'est-à-dire une capacité technique (par opposition à un élément du métier) que les entreprises souhaitent acquérir à un tarif validé par les comptables.

Et c'est là que Quentin Adam entre en scène

Enfin, Quentin, et une petite explication sur les ESN

C'est quoi le rapport avec les ESN ?

Parce qu'après tout, une ESN est simplement une entreprise de services numériques, non ? Elle offre à ses clients une prestation technique, non ?

Je pense que, dans la plupart des cas, une ESN offre un tout autre service. Si on comprend l'informatique comme un centre de coût et non un moteur de croissance, il est important de limiter ce coût. Pour le limiter, le plus efficace (en France) est de ne pas recruter de collaborateurs dans l'entreprise, parce que ça coûte cher, et qu'il est long et difficile de s'en séparer. Et c'est le service fondamental qu'offre la plupart des ESN : fluidifier la gestion de la masse salariale en permettant aux clients de disposer facilement de personnel qualifié au moment opportun.

Que je sois bien clair.

Cet objectif n'a rien de mal ni pour le client du service ni pour le fournisseur de ce service.

Mais il faut bien comprendre quelque chose : ce service n'a aucun rapport avec la production du logiciel ni avec sa qualité.

Et ça explique à mon sens pourquoi l'informatique reste, en France, un sujet de plainte chez la plupart des gens : si la qualité du logiciel produit n'a que peu de rapport avec la qualité de la prestation réalisée par un sous-traitant (et croyez-moi, les ESN conçoivent leurs contrats de prestation dans le but express de ne pas inclure la qualité technique de la prestation technique dans l'évaluation du projet, avec l'accord du client), il est évident que les logiciels réalisés, dont notre vie dépend de plus en plus, sont d'une qualité aléatoire.

Qui plus est, les ESN n'ont pas intérêt à développer des logiciels polyvalents, puisque ça limiterait le nombre de prestataires de service placés chez les clients. Pour aller plus loin, les ESN n'ont pas vraiment intérêt à permettre l'apparition d'éditeurs de logiciels, sauf ceux permettant de multiples missions d'adaptation, comme le permettent les fameux logiciels d'entreprise qui apportent une plus value douteuse, simplement parce que l'éditeur et l'ESN fournissant l'intégration sont motivés pour vendre des prestations, plus que pour fournir un service optimal.

C'est un tableau assez sombre, et malheureusement je ne sais pas trop comment en sortir. Qui plus est, ce tableau a des conséquences qu'on verra plus tard ...

Donc, j'ai chez moi une tablette légèrement obsolète (et surtout non mise à jour par son fabricant).

Puisque je déteste jeter du matériel encore en état de marche, et que la réutilisation est la clé d'un un umérique responsable (oui, c'est une référence subtile au précédent article), je me suis dit que j'allais chercher si il existe des voies moins officielles que les mises à jour constructeur. Evidement, ça existe, sur des sites russes ou autres étrangetés putaclic. Sans doute parce que c'est loin d'être simple. Jugez plutôt ...

Pour changer de distribution Android, il faut

1. Devenir root (avec KingoRoot ou autre)
2. Changer le recovery Android (puisque c'est une espèce d'OS allégé qui permet quelques opérations basiques) par TWRP qui permet de flasher des images, de faire des backups et des restaurations de l'OS installé
3. Trouver une distribution compilée pour cette tablette Lenovo 18-50 (ou A5500-F, selon les endroits)
4. Flasher cette distribution
5. Ajouter les applications Google évidement interdite de présence sur les distributions Android open-source

Ecrit comme ça, ça paraît simple.

En pratique, c'est un peu l'enfer.

1. Evidement, le root que vous avez trouvé peut ne pas marcher ...
2. Figurez-vous que Google a changé l'API permettant au recovery de flasher correctement les images (ce qui rend selon moi le terme de "flash" assez incorrect. Du coup, ceux qui vous recommandent naïvement la version "standard" de TWRP se trompent. Et pour trouver la bonne version de TWRP pour cette tablette, c'est l'enfer : j'ai fini par trouver, au fond du forum XDA, une version raisonnablement récente, malgré certains messages en russe 🤔.
3. Normalement, cette liste d'images devrait être bonne, non ?
4. Eh bien en fait, c'est au moment où on flashe une image qu'on se rend compte ... que ça ne marche pas. En testant l'image resurection remix, j'ai évidement brické ma tablette (avec ce très chouette message "Kernel image incorrect!!")
5. Et en bonus, il ne faut pas oublier de télécharger la bonne version d'opengapps ... Et chaque erreur vous coûtera cher.

Bon, et alors pour ce brick, il y a apparement une solution. Mais j’aime beaucoup l'idée d'enlever la batterie sur une tablette non démontable 😭. Bon, j'ai trouvé, hein, mais je commence à avoir un peu peur ... Et puis il faut l'identifiant du chipset (à priori, ce serait un MT6582).

Et surtout, après avoir tenté de débricker cette tablette pendant littéralement des mois, je n'ai atteint aucun résultat et transformé du matériel qui marchait en matériel qui ne marche plus, ce qui est l'une des choses que j'aime le moins.

Ces trois dernières semaines, je voyais cette montagne depuis mon lieu de vacances du matin au soir. Et c'était bien.

J'ai fait de la marche à pied (beaucoup), un peu de bateau sur le lac du Bourget qui n'est pas loin, un peu de jeux de société (dont quelques parties de BloodBowl aussi acharnées que spectaculaires).

Et puis contrairement aux autres années, je n'ai pas du tout pensé au travail.

En revanche, en rentrant, j'ai fait le point sur mes quelques dernières idées (c'est le bon moment). Je vais donc abandonner quelques projets qui n'étaient pas fait pour être réalisés

• Le plugin Keepass qui aurait permis de saisir automatiquement les chiffres dans les calculettes des sites bancaires. J'abandonne parce qu'il faut me mettre au C# et lancer une API de détection de chiffres dans l'image
• Le bout de code Python à lancer dans OBS pour générer des génériques de fin de réunion. L'idée est belle, mais je n'ai rien réalisé sur ce sujet.

En discutant ce matin avec un collègue, je vais faire exactement ce que je lui ai recommandé : je vais noter soigneusement chaque idée et essayer d'en noter autant de détails que possibles (sans doute dans un coin de ce blog) avant de juger de leur faisabilité ou pas.

Ca me permettra de décider si je dois me lancer dans une implémentation de la version de BloodBowl que j'ai chez moi en application web (spontanément, je pense que c'est une erreur, mais j'ai envie de tenter une fois dans ma vie de développer un jeu vidéo)