Atelier Logiciel Sandré

Chaos Engineering

Wed, 03 Dec 2025 00:00:00 +0000

🐒 Si vous voulez prouver qu’un système distribué est tolérant aux pannes, vous devrez essayer de le mettre en panne, en production. Que se passe-t-il si le reverse proxy tombe ? Si une région AWS entière est indisponible ? Les humains ont tendance à esquiver inconsciemment les véritables scénarios problématiques, il faut donc permettre à un robot, le Chaos Monkey, de provoquer des pannes aléatoires en injectant des données erronnées, en ajoutant de la latence ou en coupant des machines. Complétement idiot ? Non, cette technique que l’on appelle Chaos Engineering est utilisée par toutes les organisations qui se préparent sérieusement à l’inattendu. Shit happens.

📝 La manière de mener de telles campagnes de test est assez cadrée. Le papier qui en parle est assez court, je ne ferai que de le paraphraser en le résumant.

SOURCE

A. Basiri et al., “Chaos Engineering,” in IEEE Software, vol. 33, no. 3, pp. 35-41, May-June 2016, DOI:10.1109/MS.2016.60.

STADS: Software Testing as Species Discovery

Wed, 26 Nov 2025 00:00:00 +0000

🕵️ Comment savoir si la recherche de bugs sur un système touche à sa fin ? Avec des entrées complexes, il est manifestement impossible de tout essayer par bruteforce. Le fuzzing consiste à envoyer des données ayant un maximum de chances de provoquer une erreur dans un système. C’est une branche du random testing. Cependant même avec un bon fuzzer, les test peuvent être longs, voire infiniment longs.

🪹 On sait depuis plusieurs décennies qu’un fuzzer remontera des bugs selon un courbe logarithmique : plus le temps passe, moins il y aura de bugs découverts. Comment savoir quand l’énergie consommée par le fuzzer sera plus coûteuse que le retour sur investissement potentiel ?

🦋 Un réponse prometteuse vient de la zoologie, qui a le même genre de problèmes : comment savoir combien d’espèces restent à découvrir sur une zone donnée ? Une formule mathématique permet d’extrapoler le nombre d’espèces restant à découvrir (vues 0 fois) à partir de celles vues une fois et de celles vues deux fois.

🪲 Est-ce applicable aux bugs et autres vulnérabilités ? Oui, mais avec prudence car s’il est facile de savoir si l’on a 2 occurrence du même animal, il est compliqué de dire si deux bugs sont du même type ou non. Cependant la méthode offre des résultats intéressants.

SOURCE

Marcel Böhme. 2018. STADS: Software Testing as Species Discovery. ACM Trans. Softw. Eng. Methodol. 27, 2, Article 7 (April 2018), 52 pages. DOI:10.1145/3210309

On the notion of object

Wed, 19 Nov 2025 00:00:00 +0000

📦 Le concept d’objet dans les langages orientés-objet est difficile à définir. Les divergences entre les différentes “saveurs” d’orienté-objet et le drama entre auteurs explique en partie le problème. Les américains tendent à y voir seulement un mécanisme de modélisation efficace, tandis que les européens tendent à rechercher une certaine esthétique philosophique dépassant la stricte nécessité technique.

🏺 Pour comprendre ce qu’est un objet, il faut étudier la notion sous plusieurs angles, n’ayant pas tous un rapport direct à l’informatique, nous serions même parfois plus proches des mathématiques, de la psychologie et de la philosophie.

😶‍🌫️ Un objet peut être vu comme une substance attachée à une identité permettant de le distinguer des autres. Toujours dans la même veine ontologique, un objet peut aussi être défini comme l’inverse d’une valeur. Cette dernière est éternelle, immuable, universelle et sans identité. Hélas la plupart des langages ne l’entendent pas ainsi et la moindre valeur, même une primitive, est alors un objet comme un autre. En informatique, “Objet” est un terme équivoque, zut.

🛡️ L’objet peut aussi être défini comme l’inverse des fonctions. La fonction n’a aucune mémoire, elle est pure et sans effet de bord. L’objet stocke un état. Mais ce serait insuffisant car les objets exposent des opérations qui protègent l’état qu’ils contiennent contre l’écriture de valeurs invalides. Parce qu’il n’est pas référentiellement transparent, l’objet est une abstraction, masquant une partie de la complexité qu’il contient derrière une façade : son interface. Hélas encore une fois, le concepte d’abstraction de données et celui d’objet ne sont pas identiques et ne se recouvrent pas complètement. Caramba, encore raté !

🔢 Essayons alors la définition purement technique : un objet est un dictionnaire de propriétés, chacune étant un tableau d’octets que l’on regarde à travers des lunettes qui permettent de l’interpréter. Ce point de vue est probablement le plus exact, mais aussi le plus insatisfaisant, sauf peut-être pour un développeur Javascript.

➗ Essayons alors les mathématiques. Un objet est alors une machine à états finis, possédant des fonctions transformant un état en un autre. L’objet peut être décrit comme un tuple à 4 éléments : son identité, son type, son état actuel et l’ensemble des identifiants y faisant référence. L’identité est immuable, le type l’est souvent, l’état peut varier selon les règles qu’impose le type. Le type peut parfaitement imposer à l’état d’un objet une totale immutabilité, ce qui le rend référentiellement transparent. Les identifiants quant à eux sont un tableau associant des noms à un objet donné.

🧑‍🏫 Pris isolément, aucun de ces points de vue n’a la moindre utilité pratique au développeur. Tous ces points de vue sont complémentaires et offrent un éclairage complet sur un phénomène bien plus complexe qu’il n’y paraît. L’auteur cite Marvin Minsky : nous ne comprenons rien tant que nous ne l’avons pas appris de plusieurs manières.

SOURCE

Antero Taivalsaari. 1993. On the notion of object. J. Syst. Softw. 21, 1 (April 1993), 3–16. DOI:10.1016/0164-1212(93)90013-N

Microservices tenets: Agile approach to service development and deployment

Wed, 12 Nov 2025 00:00:00 +0000

🥸 Les microservices ne sont qu’une variante du style Service-Oriented Architecture (SOA). Ils n’ont rien de révolutionnaire. Les technologies ont changé, il est plus “cool” de dire qu’on fait du microservices, mais les contraintes architecturales sont rigoureusement les mêmes.

☁️ La plupart des principes qui gouvernent les microservices sont des reformulations des principes SOA. Le papier argumente fortement dans ce sens. Les microservices n’ont comme vraie nouveauté que les exigences propres à l’environnement cloud-native.

🪤 L’auteur n’évoque pas les pièges mortels du préfixe “micro”, qui n’agrémente pas de manière heureuse le mot de “service”, largement suffisant et ayant fait ses preuves.

SOURCE

Zimmermann, Olaf. (2016). Microservices tenets: Agile approach to service development and deployment. Computer Science - Research and Development. 32. DOI:10.1007/s00450-016-0337-0.

Extending ordinary inheritance schemes to include generalization

Tue, 04 Nov 2025 00:00:00 +0000

🧠 Le mécanisme cognitif que l’on nomme spécialisation nous est familier en programmation. Si un canard est un animal, alors la plupart des langages permettent de dériver un classe canard de la super-classe animal. Le chemin inverse se nomme la généralisation. Aucun langage courant ne propose de mécanisme permettant de créer une super-classe en masquant des propriétés d’une ou plusieurs sous-classes.

🌱 L’auteur propose de créer un tel mécanisme. Sa réfléxion est restée purement théorique, cependant il s’agit probablement de la graine qui donnera ultérieurement le mécanisme d’interface explicite, présent notamment en C# ou en PHP. Une interface explicite peut être déclarée après les classes qu’elle doit unir.

SOURCE

Pedersen, Claus. (1989). Extending ordinary inheritance schemes to include generalization. ACM SIGPLAN Notices. 24. 407-417. DOI:10.1145/74878.74920.

Looking for a place to hide: a study of social loafing in agile teams

Tue, 19 Aug 2025 00:00:00 +0000

😴 Les projets étudiants sont une répétition générale du monde du travail : plus le groupe est nombreux, plus les passagers clandestins pourront délibérément exploiter les autres sans se faire prendre. Le phénomène que je décris ne doit pas être confondu avec l’organisation sous-optimale d’une équipe ou les différences de niveau entre ses membres, qui ne sont pas des pertes de productivité intentionnelles mais accidentelles. Ce phénomène est appelé flânerie sociale, social loafing dans la langue de Chesterton.

😶‍🌫️ Les méthodes agiles interdisent de mesurer les performances individuelles ou d’affecter des tâches à quiconque. L’équipe est un atome (Whole Team & Collective Ownership en eXtreme Programming). On pourrait s’attendre à voir les parasites se greffer aux équipes agiles comme la misère sur le monde. Les deux cas étudiés par les chercheurs semblent montrer qu’il n’en est rien. Au contraire, les indicateurs individuels semblent plus faciles à “hacker” par les paresseux que les relations humaines d’une équipe agile.

⚠️ L’échantillon est plus que maigre, nous connaissons probablement tous des contre-exemples de cela, aussi ce résultat doit être pris avec prudence.

SOURCE

McAvoy, John and Tom Butler. “Looking for a place to hide: a study of social loafing in agile teams.” European Conference on Information Systems (2006).

Better, Not More Expensive, Faster? The Perceived Effects of Pair Programming in Survey Data

Tue, 05 Aug 2025 00:00:00 +0000

🎓 Le Pair Programming divise. Il fallait donc une revue de littérature pour trancher. Sa première conclusion est que nous manquons de données sur des vraies équipes, la plupart des études étant réalisées sur des étudiants. L’hypothèse d’une augmentation massive des coûts, abondamment soutenue par les managers, semble réfutée, même si des études de cas montrent que certaines équipes n’arrivent pas à être efficaces en pair programming. Le pair programming coûte en productivité, mais de manière modérée, ce qui est compensé par les bénéfices de la pratique.

💎 Quels sont ces bénéfices ? L’augmentation de la qualité est réelle, même si les développeurs la perçoivent bien supérieure à ce qu’elle est réellement dans les mesures. La satisfaction des développeurs augmente significativement, ce qui pourrait expliquer une si faible baisse de productivité. Un développeur motivé “glande” moins. Les bénéfices du pair programming semblent amplifiés par les autres pratiques d’XP, mais avec un faible niveau de preuves.

SOURCE

Parsons, D., Hokyoung Ryu and Ramesh Lal. “Better, Not More Expensive, Faster? The Perceived Effects of Pair Programming in Survey Data.” ACIS (2008).

A systematic literature review of literature reviews in software testing

Tue, 29 Jul 2025 00:00:00 +0000

🗜️ La littérature sur les tests est abondante, tant en matière d’études primaires que secondaires. Aucune étude tertiaire, effectuant la revue de littérature des revues de littératures, n’existait encore à propos des tests. C’est chose faite et les enseignements sont intéressants.

1️⃣ Première leçon : à l’exception du marronnier MBSE, aucun sujet populaire sur Google n’a fait l’objet de beaucoup d’études secondaires, et inversement. On retrouve ici le vieux sujet du décalage entre praticiens et chercheurs.

2️⃣ Seconde leçon : les études secondaires sur les tests foisonnent à partir de 2009. Cela montre un véritable intérêt de la communauté de recherche pour le sujet, qui est corrélé avec l’intérêt du public pour le sujet.

🎓 Les trouvailles de ce papier gagneraient à inspirer l’ISTQB. Son syllabus brille rarement par la variété et la quantité de ses sources académiques, bien qu’il en possède ce qui est rare dans notre secteur. Même commentaire pour le SWEBOK.

SOURCE

Garousi, Vahid and Mika Mäntylä. “A systematic literature review of literature reviews in software testing.” Inf. Softw. Technol. 80 (2016): 195-216.

Testing, abstraction, theorem proving: better together !

Tue, 22 Jul 2025 00:00:00 +0000

🔎 L’analyse dynamique (les tests) ne pourra jamais valider tous les comportements possibles d’un programme : elle sous-approxime. A l’inverse, l’analyse statique tend à sur-approximer et à produire un grand nombre de faux-positifs. Est-il possible de prendre le meilleur des deux mondes ? Des chercheurs proposent un moyen d’y parvenir.

🤖 Les tests sont d’abord exécutés afin d’obtenir un jeu d’états concrets du programme. Ce jeu d’états est généralisé en un jeu d’états abstraits, représentant l’ensemble des états dans lequel le programme peut potentiellement se trouver. Un démonstrateur de théorème automatisé va ensuite vérifier que ce jeu d’états abstrait vérifie certaines propriétés désirables et passe lui-même une version généralisée des tests. Si ça n’est pas le cas, le démonstrateur va générer des contre-exemples permettant au développeur d’augmenter la couverture.

🔧 Je n’ai pas trouvé d’outil appliquant ce principe. Les tests de mutation ont mis 25 ans à passer du laboratoire aux IDE, je pense que les prochaines années verront ce type d’outils venir renforcer nos pratiques.

SOURCE

Greta Yorsh, Thomas Ball, and Mooly Sagiv. 2006. Testing, abstraction, theorem proving: better together! In Proceedings of the 2006 international symposium on Software testing and analysis (ISSTA ‘06). Association for Computing Machinery, New York, NY, USA, 145–156. DOI:10.1145/1146238.1146255

Agility From First Principles: Reconstructing the Concept of Agility in Information Systems Development

Tue, 15 Jul 2025 00:00:00 +0000

😶‍🌫️ L’agilité est au départ un pur label : c’est la mise en commun de la visibilité de plusieurs méthodes autour d’un manifeste flou. Le temps n’a pas aidé à trouver une définition stable, tant le mot est revendiqué par des courants différents. Pire : le mot est antérieur à son usage dans le monde du logiciel. Un consensus se dégage autour de 2 notions : flexibilité et maigreur (leanness). Être Agile serait donc posséder ces deux traits.

🤸 La flexibilité est la capacité à changer de manière réactive ou proactive. Est-ce suffisant pour être agile ? Certainement pas. Une organisation lentement flexible ne sera pas perçue comme agile. L’agilité est également une ouverture au changement : une organisation résiliente, capable de changer au besoin, sans que le changement ne soit accueilli favorablement n’est pas agile.

⚙️ La maigreur est une emphase sur l’économie, la qualité et la simplicité dans la contribution à la valeur perçue par le client. L’inclusion de lean dans l’agilité est problématique : une organisation maigre sacrifie de la résilience pour être la plus efficiente possible. Elle n’est donc pas conçue pour changer, bien au contraire. L’agilité tord quelque peut la définition toyotiste d’origine en cherchant la manière la plus efficiente de produire dans des environnements en perpétuel changement. C’est surtout possible grâce à la nature immatérielle du code.

SOURCE

Conboy, Kieran. (2009). Agility From First Principles: Reconstructing the Concept of Agility in Information Systems Development. Information Systems Research. 20. DOI:10.1287/isre.1090.0236

Value Creation by Agile Projects: Methodology or Mystery?

Tue, 08 Jul 2025 00:00:00 +0000

💵 L’agilité est une chose étrange. Tout le monde parle de “Business Value” mais aucun auteur ne la définit sérieusement. Pour les développeurs, c’est sans doute mieux, car ils peuvent estimer leurs tâches sans retomber dans un culte du mois-homme. Pour le management, c’est bien plus problématique, car ils n’ont qu’un indicateur qualitatif, subjectif et mélangeant la valeur apportée par le logiciel avec celle apportée par le reste des fonctions de l’entreprise.

🤞 Pire, cet indicateur doit être mesuré en se mettant dans la peau du client, mais dans les faits, ce sont toujours des acteurs internes à l’entreprise qui ont ce rôle, avec tout les risques de décalage que cela produit. Une équipe de développement rusée est ainsi poussée à faire plaisir au management, non à un client réel. Formulé en termes économiques, la Business Value n’est pas directement une Dollar Value et la traduction de l’un en l’autre est tout sauf évidente.

🔀 La Business Value est floue, mais est-ce un problème ? Le but de l’agilité est de toujours sortir la tâche la plus prioritaire pour le client à un instant T, rien de plus. Elle n’a pas pour but de compter en valeur absolue, mais d’ordonner en valeur relative. Tout management fait des paris sur ce qu’il comprend du besoin de son client, l’adéquation entre Business Value et Dollar Value, calculée a posteriori, est surtout un bon moyen pour le management de savoir s’il a réussi.

SOURCE

Racheva, Z., Daneva, M., Sikkel, K. (2009). Value Creation by Agile Projects: Methodology or Mystery?. In: Bomarius, F., Oivo, M., Jaring, P., Abrahamsson, P. (eds) Product-Focused Software Process Improvement. PROFES 2009. Lecture Notes in Business Information Processing, vol 32. Springer, Berlin, Heidelberg. DOI:10.1007/978-3-642-02152-7_12

Surviving software dependencies

Tue, 01 Jul 2025 00:00:00 +0000

🕵️ Aucune entreprise n’embauche de développeur sans de couteux tests, fréquemment hors-sujet d’ailleurs. Vérification du CV, évaluation du niveau technique, voire véritable enquête de détective pour les plus anxieux. Pourtant, une fois dans l’entreprise, le développeur est parfaitement libre de taper ‘npm install’ ou autre commande similaire. Il fait entrer du code arbitraire comme dépendance du SI, sans que personne ne vienne l’embêter. Le geste est devenu naturel pour les développeurs tant il est facile. Jamais les écoles d’informatique n’abordent le sujet de la gestion irresponsable des dépendances dans notre profession.

😱 Se plaindre de l’irruption de l’IA dans le monde du développement est une panique morale tant que les entreprises ne considéreront pas sérieusement la gestion des dépendances externes de leurs logiciels. Ce papier est un condensé, le minimum vital à connaître pour ne pas mettre en danger son entreprise.

SOURCE

Russ Cox. 2019. Surviving software dependencies. Commun. ACM 62, 9 (September 2019), 36–43. DOI:10.1145/3347446A

Historical Roots of Agile Methods: Where Did “Agile Thinking” Come From ?

Tue, 24 Jun 2025 00:00:00 +0000

🔎 D’où viennent l’agilité et la mentalité agile ? Les chercheurs ont bien du mal à répondre à cette question, tant le légendaire, l’informel et la reconstruction a priori divergent d’avec les sources authentifiées.

🌀 Beaucoup d’idées viennent évidemment des méthodes “pré-agiles” des années 80-90 comme EVO de Tom Glib ou RAD : le concept de livraison continue à partir d’un MVP et l’objectif ultime de livrer un maximum de valeur au client tirent leur origine de ces méthodes. Il n’est pas impossible que les travaux de Lehman et de Boehm soient indirectement derrière.

📜 Dijkstra et son “Humble Programmer” semble un ouvrage fondateur, au même titre que “Death March” de Yourdon et “The Cathedral and the Bazaar” de Raymond. Rien de scientifique, mais ce sont des ouvrages sapientiaux encore recommandés aujourd’hui.

🧟 Le reste n’a soit aucune origine connue, soit manque de preuves et relève de la légende plus que de l’histoire du logiciel, comme l’origine de Crystal selon Cockburn ou celle d’XP selon Beck.

SOURCE

Abbas, N., Gravell, A.M., Wills, G.B. (2008). Historical Roots of Agile Methods: Where Did “Agile Thinking” Come From?. In: Abrahamsson, P., Baskerville, R., Conboy, K., Fitzgerald, B., Morgan, L., Wang, X. (eds) Agile Processes in Software Engineering and Extreme Programming. XP 2008. Lecture Notes in Business Information Processing, vol 9. Springer, Berlin, Heidelberg. DOI:10.1007/978-3-540-68255-4_10

Exploring the duality between product and organizational architectures: A test of the “mirroring” hypothesis

Tue, 17 Jun 2025 00:00:00 +0000

🪞 « Toute organisation qui conçoit un système, au sens large, concevra une structure qui sera la copie de la structure de communication de l’organisation. ». Tout le monde connaît la Loi de Conway, que les chercheurs appellent “hypothèse miroir”. Trop peu sont au courant qu’il s’agit d’une hypothèse validée par la recherche en sociologie du logiciel.

🪢 Prenez plusieurs logiciels réalisant une fonction similaire, comparez leurs architectures à la structure des organisation qui les ont développés. Une correlation va se retrouver entre le couplage de l’organisation et la modularité du projet. Les chercheurs avancent des hypothèses pour expliquer cela, mais aucune n’est testée.

SOURCE

Alan MacCormack, Carliss Baldwin, John Rusnak, Exploring the duality between product and organizational architectures: A test of the “mirroring” hypothesis, Research Policy, Volume 41, Issue 8, 2012, Pages 1309-1324, ISSN 0048-7333, DOI:10.1016/j.respol.2012.04.011.

Exploiting style in architectural design environments

Tue, 10 Jun 2025 00:00:00 +0000

🖌️ Les styles sont au coeur de l’architecture logicielle. Ce sont eux qui définissent les typologies concrètes de connecteurs et de composants, ainsi l’interprétation sémantique à donner aux compositions d’éléments contraints par les règles qu’ils édictent.

🌅 Les styles les plus courants de cette époque n’ont rien de suranné pour le praticien de 2025 :

Pipes&Filters a retrouvé une jeunesse avec les ETL et les outils Low-Code.
Le style appelé Real-Time ressemble furieusement à nos architectures réactives.
Le syle Event-Based, aussi appelé Pub-Sub est simplement partout à l’heure des microservices, pas toujours pour le meilleur.

🔧 Ce papier visait à créer un outil générique permettant de représenter les styles architecturaux, s’il n’a pas survécu, la synthèse de ce concept peut encore nous apprendre beaucoup aujourd’hui.

SOURCE

David Garlan, Robert Allen, and John Ockerbloom. 1994. Exploiting style in architectural design environments. In Proceedings of the 2nd ACM SIGSOFT symposium on Foundations of software engineering (SIGSOFT ‘94). Association for Computing Machinery, New York, NY, USA, 175–188. DOI:10.1145/193173.195404

Betclic & Frank Recruitement Group

Sun, 01 Jun 2025 00:00:00 +0000

Betclic - Juin 2025 - Septembre 2025 - Bordeaux

Mission à temps plein, au sein de l'équipe Turf (paris hippiques) de Betclic. L'équipe travaille en Scrum, avec une stack .NET.

Software Architecture

Tue, 27 May 2025 00:00:00 +0000

🔬 L’architecture fut d’abord un artisanat, transmis d’architecte en architecte. Les nouveaux styles étaient des variations de styles existants. Les chercheurs vinrent identifier des patterns, afin de théoriser et de rationnaliser cette discipline au cours des années 1990. Le but était d’identifier des styles courants, afin de permettre leur réemploi. Les design patterns devaient bien avoir leur équivalent en architecture.

👓 Des langages descriptifs sont nés, chacun supportant une vue précise de l’architecture. Un même système n’est pas représenté de la même manière par les développeurs, les ingénieurs réseaux et aujourd’hui par les DevOps et les gens du Cloud. Tous sont au moins d’accord sur l’existence de deux choses : des composants et des connecteurs qui les relient.

🏢 L’architecture fut d’abord un artisanat et peut-être aurait-elle dû en rester là, co-évoluant avec les chercheurs. Les années 2000 l’ont vue s’industrialiser. Les styles se sont calcifiés en frameworks, les environnements se sont fermés. L’architecture est passée du jeu de Lego au lit de Procuste. L’autorité normative n’est plus le chercheur, mais celui qui vend son framework au plus d’entreprises possible. Un vaste marché de l’édition et de la formation a terminé de fragmenter la discipline en chapelles. Ce papier date seulement de 2001 et il le déplore déjà.

SOURCE

D. Garlan, “Software Architecture”, Carnegie Mellon University, 2001, doi:10.1002/9780470050118.ecse375

A field guide to boxology: preliminary classification of architectural styles for software systems

Tue, 20 May 2025 00:00:00 +0000

📋 Peut-on classer les styles architecturaux comme les design patterns l’ont été dans les années 1990 ? Le travail de Shaw et Clements s’est voulu une première pierre à un tel édifice. 2 familles ont été analysées : Pipes&Filters et Cooperative Message-Passing Processes. Chacune compte plusieurs styles, classés sur 11 critères et brièvement décrits.

🌱 Les auteurs donnent un arbre de décision permettant de choisir le bon style selon les exigences du projet, esquissant un lien qu’approfondira Roy Fielding quelques années plus tard.

🫢 Hélas ce travail reste aujourd’hui sans suite, 30 ans plus tard. Le praticien doit se débrouiller avec des billets de blog approximatifs pour sélectionner un style architectural convenant aux exigences de son projet. Le choix d’un style architectural obéit bien plus aux modes du moment qu’à des critères de décision rationnels.

SOURCE

Shaw, Mary and Paul C. Clements. “A field guide to boxology: preliminary classification of architectural styles for software systems.” Proceedings Twenty-First Annual International Computer Software and Applications Conference (COMPSAC’97) (1997): 6-13. DOI:10.1109/CMPSAC.1997.624691

Reconciling the Needs of Architectural Description with Object-Modeling Notations

Tue, 13 May 2025 00:00:00 +0000

🙅 UML est-il un bon langage pour représenter l’architecture ? Non, pour deux raisons principales. La première est qu’il n’offre aucune manière meilleure que les autres de représenter les composants, les connecteurs et les notions associées en UML. La seconde est que parmi toutes les manières de faire, aucune ne permet de restituer fidèlement ces concepts dans leur intégralité.

😶‍🌫️ Il n’est pas interdit d’utiliser UML, le monde de l’architecture est une jungle sans standards véritables, mais il vaut mieux être conscient de ses limites et définir d’entrée de jeu une manière non-ambigüe de représenter les éléments de l’architecture.

SOURCE

Garlan, David & Cheng, Shang-Wen & Kompanek, Andrew. (2002). Reconciling the needs of architectural description with object-modeling notations. Sci. Comput. Program.. 44. 23-. DOI:10.1016/S0167-6423(02)00031-X.

The golden age of software architecture

Tue, 06 May 2025 00:00:00 +0000

🔎 L’architecture logicielle est née dans la seconde moitié des années 80. Il s’agissait pour les chercheurs d’identifier les solutions que les praticiens avaient imaginées pour orchestrer des systèmes logiciels comportant de nombreux modules. La théorisation, d’abord balbutiante, s’est faite dans les années 1990. Le fouillis qu’est encore aujourd’hui l’architecture, où cohabite bullshit et pépites, vient de cette théorisation parcellaire et a posteriori.

🌟 Les années 2000 sont qualifiées d’âge d’or de l’architecture par les auteurs de cet article de synthèse. Les premiers standards sont établis, les premières formations sont dispensées et les éditeurs vomissent des dizaines de livres plus ou moins inspirés. Il aura fallu 20 ans. Quiconque connaît la manière dont les technologies maturent ne sera pas surpris.

🚀 Notre papier du jour a été publié en 2006. Ses auteurs n’ont pas connu le désamour des développeurs pour l’architecture dans les années 2010, ni sa réappropriation actuelle, sous l’impulsion du mouvement craft. Quelle sera la suite de l’histoire ? A nous de l’écrire, en espérant qu’elle se fasse sans UML, déjà qualifié d’erreur dans ce papier.

SOURCE

M. Shaw and P. Clements, “The golden age of software architecture,” in IEEE Software, vol. 23, no. 2, pp. 31-39, March-April 2006, DOI:10.1109/MS.2006.58

Classes versus prototypes in object-oriented languages

Tue, 29 Apr 2025 00:00:00 +0000

🤯 L’idée de baser l’orienté objet sur des prototypes plutôt que sur des classes date de 1986. C’est une réaction à l’introduction des métaclasses en Smalltalk, concept jugé très peu intuitif (les pythonistes modernes témoigneront). Borning affirme que les classes des langages orientés-objet portent bien trop de responsabilités : générateurs d’instances, descripteurs de protocoles, descripteurs de représentation, etc.

📑 La solution proposée est d’abolir les classes. Tout nouvel objet est la copie d’un ancien, qui peut ensuite être modifié à loisir. Cette copie peut être indépendante de la source, ou lui être liée par des contraintes. Ces contraintes peuvent lier ensemble les champs, le comportement ou le protocole des deux objets. Une copie contrainte sur les trois se nomme un descendant.

🚫 Aucune étude, même sur des étudiants, n’a été effectuée avant d’affirmer que ce modèle est plus clair que la POO “vanilla” ou les métaclasses. Pourtant l’auteur affirme qu’ayant moins de concepts à apprendre, le débutant sera moins perdu. Celui-ci est pourtant clairvoyant sur les défauts de sa proposition : elle n’est pas naturelle pour les pures abstractions comme les nombres. Quel est l’entier prototypal ? 0 ou 1 ? Un prototype de Stack ou de Queue fait-il sens ? Enfin, à l’époque, le copy-on-write n’existait pas et les performances d’un langage à prototype n’auraient pas été flamboyantes.

🏛️ La philosophie aristotélico-thomiste est gravée dans nos têtes d’occidentaux, pour le meilleur et pour le pire. Sortir de cette dualité objet/concept est une impasse en programmation, car cette dualité nous est enseignée depuis notre enfance. Qu’elle soit naturelle ou culturelle importe peu à ce stade.

SOURCE

A. H. Borning. 1986. Classes versus prototypes in object-oriented languages. In Proceedings of 1986 ACM Fall joint computer conference (ACM ‘86). IEEE Computer Society Press, Washington, DC, USA, 36–40. DOI:10.5555/324493.324538

Contracts: specifying behavioral compositions in object-oriented systems

Tue, 15 Apr 2025 00:00:00 +0000

📃 Les contrats ont été inventés en 1990 afin de compléter les interfaces des classes. Ces dernières donnent les signatures des méthodes exposées par une classe, mais ne disent rien du comportement que chacune des parties attend de l’autre. Les commentaires sont largment insuffisants, car il faut que de telles spécifications soient exécutables.

🌱 La première idée émise par les chercheurs fut d’intégrer les contrats dans les langages de programmation eux-mêmes. Cette idée n’a pas pris, mais les contrats sont loin d’être morts ! Les tests fonctionnels sont les héritiers directs de ce morceau d’histoire du logiciel. Plus éloignés, certains types de foncteurs (Maybe, Lazy, Either, …) ou les systèmes de Tasks/Promises peuvent se rattacher à des contrats.

SOURCE

Richard Helm, Ian M. Holland, and Dipayan Gangopadhyay. 1990. Contracts: specifying behavioral compositions in object-oriented systems. SIGPLAN Not. 25, 10 (Oct. 1990), 169–180. DOI:10.1145/97946.97967

Green code : towards measuring the efficiency of software system execution

Wed, 09 Apr 2025 00:00:00 +0000

🪫 Comment produit-on un logiciel économe en énergie ? Sans surprise, il faut déjà que le besoin en soit exprimé. C’est une exigence non-fonctionnelle et aucun développeur ne s’en préoccupe si ça n’est pas formulé sous forme d’objectifs chiffrés.

📏 Ensuite, il faut que le développeur puisse mesurer la consommation de son programme. Il faut de l’outillage pour cela, notamment en intégration continue. Hélas le papier reste en surface et ne nous dit pas lesquels.

⚡ Mesurer ne sert à rien si l’on ne peut pas agir. Les développeurs doivent se former à repérer les antipatterns énergétiques au niveau architectural, dans le design ou les structures de données. Certains patterns sont connus pour favoriser les économies d’énergie. Problème : certaines bonnes pratiques logicielles semblent alourdir le bilan energétique des projets, comme l’encapsulation, en tout cas sur certains langages. A l’inverse, le bon usage du multithreading permet souvent des économies importantes. Plus surprenant, la pratique du refactoring semble liée à une meilleure efficacité energétique.

👟 Tous les frameworks, bibliothèques et bases de données ne se valent pas, certains sont des gouffres énergétiques, l’auteur note hélas que ce sont souvent les dépendances les plus performantes qui sont aussi les moins efficientes. Cette tension se retrouve également dans les réglages des compilateurs C/C++ où les optimisations les plus aggressives ne sont pas toujours les plus vertes. Sans surprise, la conteneurisation, voire pire la virtualisation sont des gouffres énergétiques.

SOURCE

Rifat, Ahmed, Green code : towards measuring the efficiency of software system execution. School of Engineering Science, Tietotekniikka. 2022.

Secure Software Development Methodologies: A Multivocal Literature Review

Tue, 25 Mar 2025 00:00:00 +0000

🔒 Les méthodologies de Secured Software Development sont nombreuses, populaires et font même l’objet de normes gouvernementales depuis une demi-décennie. Trois raisons de s’en méfier, donc.

📐 Chercheurs, gouvernements et praticiens s’accordent sur un socle commun de pratiques : évaluation des risques, création d’une culture de la sécurité et standards de code. En dehors de ce noyau commun, les pratiques recommandées divergent.

🤡 Les auteurs de cette revue de littérature relèvent l’absence quasi-totale de justification des pratiques recommandées par ces méthodologies. La charge de la preuve leur incombe, pourtant. Ils notent également l’absence d’évaluation de l’efficacité de telles méthodologies, pointant ironiquement que les entreprises desquelles elles sont issues ont été remarquées pour des hacks massifs depuis la parution de leurs méthodes.

⛓️ Ajoutons que très peu de méthodes envisagent le développeur comme un acteur de la sécurité. Au mieux leur impose-t-on des standards de code et des revues de leur travail par des experts. La plupart des frameworks se contentent de faire de la gestion de risque, à mille lieux de méthodologies de développement, sécurisé ou non.

SOURCE

Kudriavtseva, Arina and Olga Gadyatskaya. “Secure Software Development Methodologies: A Multivocal Literature Review.” ArXiv DOI:abs/2211.16987 (2022)

Hints on Test Data Selection: Help for the Practicing Programmer

Tue, 18 Mar 2025 00:00:00 +0000

🧪 En 1978, quasiment tout ce qu’un développeur de 2025 doit savoir sur les tests avait déjà été dit. Comment sélectionner les cas de test pour éviter le Happy Path Testing ? Goodenough et Gerhart en 1975. L’idée des tests de mutation ? Budd, DeMillo et Lipton en 1978. L’hypothèse du programmeur compétent ? Youngs en 1971. Le rapport logarithmique entre effort de test et découverte de bugs ? Tucker en 1965.

🥊 Ce papier de 1978 vulgarise avec brio tous les concepts susmentionnés. En 2025, personne n’a d’excuses pour les ignorer, sinon un parcours de formation défaillant.

SOURCE

DeMillo, Richard A., Richard J. Lipton and Frederick G. Sayward. “Hints on Test Data Selection: Help for the Practicing Programmer.” Computer 11 (1978): 34-41. DOI:10.1109/C-M.1978.218136

Agile Gets Physical : Slice-Based Integration

Tue, 11 Mar 2025 00:00:00 +0000

🤖 L’agilité fait grincer les dents dans le monde du hardware. Réaliser une carte électronique est tellement long que personne ne s’amuse à ajouter chaque feature itérativement. Ca n’est même pas physiquement possible dans la plupart des cas.

🚧 Le hardware connaît cependant le développement incrémental, c’est là que nous pouvons nous entendre. Avant le produit fini, l’ingénieur conçoit tout un bestiaire de prototypes de plus en plus aboutis, avec lesquels les développeurs peuvent composer pour exécuter les tests du software.

⌚ Peu d’effort est demandé au hardware : seulement de s’aligner sur des jalons convenus avec les développeurs. Chaque jalon spécifie un ensemble de cas d’utilisation que toutes les équipes devront tester ensemble de manière intégrée à une échéance donnée. Chacun retourne travailler après s’être accordé sur une interface commune, permettant le développement de doubles de test propres à chacun. Le jour J, on met en commun et on teste. Les réalignements se font à l’incrément suivant jusqu’au produit fini.

⚠️ Cette méthode semble prometteuse, mais ce papier ne fait que la présenter, sans conduire d’étude prouvant son efficacité.

SOURCE

Iberle, Kathleen (2022). Agile Gets Physical : Slice-Based Integration. PNSQC Proceedings.

Encapsulation and inheritance in object-oriented programming languages

Tue, 04 Mar 2025 00:00:00 +0000

📦 L’orienté-objet moderne ne s’est pas figé du jour au lendemain. Les différences entre les langages actuels portent les cicatrices des débats qui ont eu lieu dans les années 1980, à l’époque où ce paradigme se consolidait. Ces papiers n’ont plus aucun intérêt scientifique, sauf pour les amoureux de l’histoire du logiciel qui y trouveront les minutes des débats qui ont animé la communauté objet.

❓ Alan Snyder explore ici les liens pas si évidents entre héritage et encapsulation. L’enfant doit-il accéder aux parties privées du parent ? Être traité en étranger ? Quelque chose entre les deux (ce qui deviendra le mot clé protected) ? Le fait qu’une classe hérite d’une autre doit-il être une information accessible au reste du programme ? Ces questions ont été tranchées, mais il est toujours intéressant de comprendre le chemin intellectuel qui nous a mené à la situation actuelle.

SOURCE

Snyder, Alan. “Encapsulation and inheritance in object-oriented programming languages.” OOPLSA ‘86 (1986). DOI:10.1145/960112.28702

Designing Reusable Classes

Tue, 25 Feb 2025 00:00:00 +0000

🧊 Certains papiers sont des instantanés des erreurs de leur époque et méritent leur place ici principalement pour cela. Le début de celui-ci est une description claire et impeccable de ce qu’est l’orienté-objet à la fin des années 80. Presque rien n’a changé depuis, seulement quelques additions mineures.

🔗 La suite porte sur les frameworks : ils y sont correctement décrits comme étant plus que de simples boîtes à outils. Tout framework lie irrévocablement le code qui l’utilise à une architecture. L’auteur rappelle une distinction aujourd’hui oubliée entre frameworks white-box et black-box, les premiers ayant presque disparu du marché.

✅ La fin du papier liste des “bonnes pratiques” de l’époque, certaines aujourd’hui réfutées. L’usage de hiérarchies d’héritage profondes est recommandée, alors que nous savons désormais que le nombre de niveaux d’héritage est corrélé au nombre de bugs. La création d’un maximum de code générique et même de frameworks y est encouragée, bien que décrite comme dangereuse, afin de réutiliser au maximum le code. Aujourd’hui il est recommandé d’attendre qu’un besoin de réutilisation existe pour entamer une telle démarche.

🧑‍🔬 Il est dommage que l’auteur n’ait pas cherché de preuves de l’efficacité de ces différentes règles, mais se soit simplement fait l’écho de l’esprit du temps.

SOURCE

Johnson, Ralph & Foote, Brian. (1988). Designing Reusable Classes. Journal of Object-Oriented Programming.

Values and objects in programming languages

Tue, 18 Feb 2025 00:00:00 +0000

🗃️ Les familiers de DDD connaissent la distinction Entité/Objet-Valeur. Peu savent qu’Evans n’a rien inventé : en 1982, Bruce McLennan plaidait pour que les langages orientés-objet n’utilisent pas le même mécanisme pour représenter les valeurs et les objets. Les premières sont des abstractions intemporelles et immuables que la programmation partage avec les mathématiques. Les seconds sont des instances partageant une forme commune (leur classe), mais différent en substance (leur identité et leurs accidents).

🧮 En réalité, McLennan non plus n’a rien inventé, il poursuit simplement la longue tradition d’Aristote, de Saint Thomas d’Aquin et des scolastiques. L’orienté-objet n’a rien de neutre, ce paradigme est l’héritier d’une longue tradition philosophique réaliste. Pour McLennan, les mathémathiques sont trop abstraites et incommodes pour représenter les cas particuliers. A l’inverse, un style de programmation qui ignore la distinction valeur/objet se prive d’outils puissants pour représenter l’abstrait, l’immuable, le calculable et donc la simplicité.

🏛️ Ce papier est à ranger parmi les grands classiques de la programmation. “Programmer, c’est faire des mathémathiques orientées-objet. Mathématiser, c’est faire de la programmation orientée-valeur” résume d’auteur.

SOURCE

MacLennan, Bruce J.. “Values and objects in programming languages.” ACM SIGPLAN Notices 17 (1982): 70-79. DOI:10.1145/988164.988172

Evaluation of Approaches for Documentation in Continuous Software Development

Tue, 11 Feb 2025 00:00:00 +0000

📖 Même un code exemplaire a besoin d’être accompagné d’une documentation. Concevoir c’est faire des choix, qui doivent être consignés quelque part pour être compris dans le futur. A l’heure actuelle, deux approches ont le vent en poupe : “Just enough Upfront” et “Executable Documentation”. Elles sont trop récentes pour en évaluer les résultats, mais il est cependant possible de baliser le terrain et de savoir de quoi il en retourne.

🖼️ Just enough up Front utilise des supports de documentation déstructurés en amont du développement : présentations, description d’interfaces, schémas. Le développement démarre dès que suffisamment d’informations sont récoltées, et utilise l’abstraction pour garder le code extrêmement perméable au changement. La documentation in fine est le code lui-même, ainsi que les messages de commits.

🧪 Executable Documentation utilise massivement les méthodes de recueil du besoin piloté par les tests, les spécifications et exigences exécutables tout au long du cycle de vie du logiciel. Le reverse engineering est une méthode d’extraction de la connaissance adaptée avec une telle couverture du code.

🧭 Tandis que Just enough up Front est déjà bien installé en entreprise, Executable Documentation souffre de l’obsession mondiale pour les tests unitaires, incapables de supporter cette méthode. C’est dommage car les deux méthodes se complètent bien. L’une permet de savoir où l’on va, l’autre de ne pas oublier ce que l’on voulait accomplir.

📍 Git est le lieu parfait pour documenter du code dans le cadre de ces deux démarches, notent les chercheurs. Les messages de commits sont sous-cotés.

SOURCE

Theunissen, Theo & Hoppenbrouwers, Stijn & Overbeek, Sietse. (2023). Evaluation of Approaches for Documentation in Continuous Software Development. 404-411. DOI:10.5220/0011846200003464.

Understanding and Detecting Harmful Code

Tue, 04 Feb 2025 00:00:00 +0000

🐛 La plupart des odeurs du code ne sont pas corrélées à la présence de bugs et inversement, la plupart des bugs ne sont pas liés à des odeurs du code. Ces deux concepts désignent des réalités différentes. Une seule odeur du code ressort du lot en étant modérément corrélée à l’apparition de bugs : l’appel de méthodes abstraites depuis le constructeur. S’il faut prioriser un refactoring c’est bien celui-ci.

🔎 Le papier vise surtout à améliorer les outils de détection de bugs. En remontant depuis les odeurs jusqu’aux métriques permettant de les détecter automatiquement, les chercheurs en ont sélectionné plusieurs qui sont modérément corrélées à l’apparition de bugs. Rien de surprenant pour un développeur chevronné : nombre excessif de paramètres, nombre excessif de méthodes par classes, complexité ou longueur extrême d’une méthode. Rien de nouveau sous le soleil.

SOURCE

Rodrigo Lima, Jairo Souza, Baldoino Fonseca, Leopoldo Teixeira, Rohit Gheyi, Márcio Ribeiro, Alessandro Garcia, and Rafael de Mello. 2020. Understanding and Detecting Harmful Code. In Proceedings of the XXXIV Brazilian Symposium on Software Engineering (SBES ‘20). Association for Computing Machinery, New York, NY, USA, 223–232. DOI:10.1145/3422392.3422420

Identification and measurement of Requirements Technical Debt in software development: A systematic literature review

Tue, 28 Jan 2025 00:00:00 +0000

💰 Depuis Ward Cunningham, le concept de dette technique a été étendu, souvent abusivement. L’une de ses ramifications contemporaines, la dette technique d’exigence (requirements technical debt) désigne tout écart entre les spécifications idéales et les spécifications réelles du projet. On y retrouve l’exclusion de certaines parties prenantes, les mauvaises techniques d’élicitation, l’implémentation non-conforme. Dette ou malfaçon, je vous laisse juges, mais vu que le terme est utilisé en recherche, il faut bien l’accepter pour débattre du sujet.

🤝 Les pricipaux remèdes sont la revue des spécifications par le client (encore faut-il un format qu’il puisse lire) et le recueil du besoin en face à face, non par documents interposés. De vieilles recettes.

🧮 La quantification et la priorisation de la dette technique sont des sujets prometteurs mais complexes. La dette intentionnelle, celle de la définition d’origine, est facile à quantifier et à prioriser. La quantification de dette non-intentionnelle relève de la divination. Le concept recouvre surtout des failles organisationnelles qui n’ont rien à voir avec la métaphore d’une “dette”. La dette technique d’exigences n’en fait pas partie et les auteurs recommandent plus volontiers de prévenir que de quantifier, prioriser et remédier à un recueil du besoin défaillant.

* Le lien redirige vers le dernier preprint, car le papier définitif est derrière un paywall.

SOURCE

Melo, Ana & Fagundes, Roberta & Lenarduzzi, Valentina & Santos, Wylliams. (2022). Identification and measurement of Requirements Technical Debt in software development: A systematic literature review. Journal of Systems and Software. 194. 111483. 10.1016/j.jss.2022.111483.

How Does Modern Code Review Impact Software Design Degradation? An In-depth Empirical Study

Mon, 20 Jan 2025 00:00:00 +0000

💣 Les Code Reviews n’empêchent pas l’érosion du design d’un logiciel, voire l’aggravent dans certains cas. Si une review n’est pas explicitement dédiée à l’amélioration du design, mieux vaut d’abstenir d’y toucher. Même lorsqu’une review s’intéresse explicitement au design, elle tend à ne régler que les problèmes localisés et n’a pas d’impact sur les problèmes plus larges, nécessitant le remaniement de nombreux éléments.

🥊 Plus une review est conflictuelle et s’enlise dans les débats, plus le design a de chances d’être dégradé. L’amélioration d’un aspect du design tend de surcroît à se faire au détriment d’autres éléments. Seul l’implication véritablement active de plusieurs reviewers permet de sauver les meubles. A ce prix là, ne serait-il pas plus pertinent de faire directement réaliser le code par plusieurs devéloppeurs ?

SOURCE

Uchôa, Anderson & Barbosa Vieira da Silva, Caio & Oizumi, Willian & Blenilio, Publio & Lima, Rafael & Garcia, Alessandro & Bezerra, C. I. M.. (2020). How Does Modern Code Review Impact Software Design Degradation? An In-depth Empirical Study. DOI:10.1109/ICSME46990.2020.00055.

Evolution of Software Testing Strategies and Trends: Semantic Content Analysis of Software Research Corpus of the Last 40 Years

Wed, 15 Jan 2025 00:00:00 +0000

⌚ 40 ans de recherche sur les tests résumés en un papier académique ? Une équipe turco-norvégienne l’a réalisé. Il s’agit ici de recenser les grandes tendances de chaque demi-décennie, de manière quantitative.

🧪 L’intérêt des chercheurs pour les tests naît dans les années 80 où la recherche se concentre sur l’outillage adéquat et la détection des bugs. La décennie 90 a exploré le sujet de la génération des cas de tests. Les années 2000 ont évalué les résultats des différentes approches de manière empirique avant que la décennie qui nous précède ne s’intéresse à la prédiction des défauts. Les chercheurs parient que l’avenir vera des percées dans la sécurité, l’open-source et le mobile.

🗨️ Ce papier est utile pour qui veut connaître les grands courants de la recherche, sans discriminer les papiers qui ont fait école de ceux qui sont tombés dans l’oubli. L’exercice est intéressant mais mériterait une suite où chaque papier est pondéré selon le nombre et la longévité des citations.

SOURCE

Gurcan, Fatih & Menekşe Dalveren, Gonca & Cagiltay, Nergiz & Roman, Dumitru & Soylu, Ahmet. (2022). Evolution of Software Testing Strategies and Trends: Semantic Content Analysis of Software Research Corpus of the Last 40 Years. IEEE Access. PP. 1-1. DOI:10.1109/ACCESS.2022.3211949.

Test-Driven Development with the Focus on Inexperienced Programmers: A Literature Review

Tue, 07 Jan 2025 00:00:00 +0000

🧪 Chez les débutants, TDD et TLD permettent d’atteindre une qualité produit similaire. Ces résultats sont confirmés par une revue de littérature de 2022. Celle-ci nous apprend aussi que TDD permet une meilleure couverture de tests que TLD, donc potentiellement une meilleure capacité anti-régression, mais est plus difficile à apprendre. Les pièges sont nombreux pour les débutants en TDD : les étudiants tendent à ne pas comprendre immédiatement la démarche et à ne pas refacto une fois les tests au vert. Ils sont souvent adeptes du happy-path testing, donc de tests peu approfondis. Avec de l’entraînement et un suivi correct, ces problèmes sont rapidement corrigés.

SOURCE

Nyman A, Rimmi O. Test-Driven Development with the Focus on Inexperienced Programmers: A Literature Review. 2022.

Madic & Frank Recruitement Group

Wed, 01 Jan 2025 00:00:00 +0000

Madic - Janvier 2025 - Juin 2025 - St André de Cubzac

Le groupe Madic m'a confié l'internalisation d'un projet C# jusque là développé par une ESN. Il s'agit d'un jeu d'applications critique pour le groupe, puisqu'il gère la remontée d'alarmes dans les stations.

Le projet a d'abord été audité, afin d'obtenir un état des lieux du code et de l'architecture. Un rapport destiné aux exécutifs a été rédigé. Une fois ceci fait, un vaste chantier de simplification a permis de diminuer une complexité logicielle hors de contrôle, sans perte de fonctionnalités. La protection contre les régressions a nécessité une réécriture des tests unitaires du projet, afin d'en faire des tests d'acceptation.

Les équipes internes sont formées à reprendre le projet, notamment les tests. Elles m'assistent petit à petit dans son assainissement. L'objectif est de les rendre totalement autonomes sur le projet, tant dans la maintenance que dans les évolutions.

En parallèle, un chantier de découpe d'un logiciel Legacy a été entrepris. L'existant en production n'a aucun test, mais doit évoluer dans les prochaines années. Le projet a été découpé par slicing afin d'obtenir des applications plus petites et maîtrisables. L'une d'entre elles, qui doit porter l'essentiel des changements, a été transférée sur une stack plus récente. Le reste sera progressivement décommissionné et remplacé par de nouveaux composants.

Iteration Causes, Impact, and Timing in Software Development Lifecycle: SLR

Tue, 17 Dec 2024 00:00:00 +0000

🔁 Itérer est toujours une perte de temps et d’argent. Un développeur omniscient recueillant un besoin parfait travaille de manière linéaire. Aucune itération volontaire ne lui est nécessaire, car le problème est bien défini. Il ne cause pas d’itérations involontaires car il produit un code simple, exempt de défauts, adéquat par rapport au besoin, sans aucune ambiguïté.

🧚 Si nous quittons le monde des fées, l’itération est bourrée d’avantages : qualité en hausse donc baisse des défauts, meilleure lisibilité donc meilleure maintenabilité, plus faible complexité donc plus grande productivité, adoption d’une solution plus adaptée au problème et plus innovante. Autrement dit, itérer c’est compenser nos limites bien humaines par une méthode d’amélioration continue. Nous sommes en négociation permanente avec les autres parties prenantes, nous-même et surtout la froide logique des machines.

🪙 La seule raison pertinente de ne pas itérer, c’est de gagner du temps à court-terme, au détriment du temps long. C’est ce que l’on appelle la dette technique.

📚 Voici les conclusions d’une équipe pakistano-saoudienne, qui a réalisé une SLR sur près de 153 études après sélection qualitative.

SOURCE

Mumtaz, Mamoona & Ahmad, Naveed & Ashraf, M. Usman & Alghamdi, Ahmed & Bahadad, Adel & Almarhabi, Khalid. (2022). Iteration Causes, Impact, and Timing in Software Development Lifecycle: SLR. IEEE Access. 10. 1-1. DOI:10.1109/ACCESS.2022.3182703.

Debugging reinvented

Tue, 10 Dec 2024 00:00:00 +0000

🔍 Une fois localisée l’origine de l’erreur, celui qui débugge doit savoir pourquoi la valeur est erronnée. Les débuggers actuels sont laborieux car ils expliquent quelle est la valeur d’une variable, non qui la lui a donnée. Une équipe de Carnegie-Mellon a conçu un outil fonctionnel permettant de suivre les éditions successives d’une variable afin de répondre à la question la plus chronophage du debug : pourquoi ?

💣 Ils sont mêmes allés plus loin : parfois une valeur devrait changer, mais ne change pas. A l’aide d’heuristiques simples, ils ont pu répondre également à la question “pourquoi pas ?”.

❓ A ce jour, je ne connais aucun outil de debug utilisant ce principe. Quelqu’un en connaît-il un ?

SOURCE

Ko, Amy J. and Brad A. Myers. “Debugging reinvented.” 2008 ACM/IEEE 30th International Conference on Software Engineering (2008): 301-310. DOI:10.1145/1368088.1368130

Finding Failure Causes through Automated Testing

Tue, 03 Dec 2024 00:00:00 +0000

🐛 Une révision fonctionne, alors qu’une autre bugge. C’est presque une routine. Le développeur doit alors rechercher la cause racine du bug et la corriger. L’usage de tests dans ce processus est ancien, bien qu’il ne soit apparu dans la littérature scientifique qu’autour des années 2000. L’idée est simple : reproduire le bug dans un cas de test pour l’empêcher de revenir. C’est le defect testing. Hélas, cette technique n’aide pas à trouver la cause racine, ce qui représente 95% du temps de debug.

🧪 Deux chercheurs allemands proposent d’utiliser les tests afin de repérer la cause racine. Il faut pour cela deux révisions séparées par un delta. Dans la première, le test de défaut fonctionne, dans l’autre celui-ci est cassé. L’étape suivante est de trouver le scénario minimal dans lequel le bug se produit, en diminuant la quantité de changements du delta. Cette étape n’est pas obligatoire, mais réduit largement la quantité de calculs nécessaires ensuite. La dernière étape consiste à muter le code afin de trouver le plus petit jeu de changements provoquant le bug, donc faisant passer au rouge le test de défaut. Cette étape est extrêmement lourde en calculs, car le nombre de mutants à générer et tester est immense.

🗜️ Cette technique n’est pas utilisée en l’état par les praticiens, à ma connaissance. Elle pourrait cependant être à l’origine du shrinking utilisé en property-based testing.

SOURCE

Cleve, Holger and Andreas Zeller. “Finding Failure Causes through Automated Testing.” arXiv: Software Engineering (2000) DOI:10.48550/arXiv.cs/0012009

The Impact of using a Contract-Driven, Test-Interceptor based Software Development Approach

Mon, 25 Nov 2024 00:00:00 +0000

📃 La programmation par contrats est impopulaire, malgré ses preuves d’efficacité. Pour la rendre sexy, des chercheurs ont envisagé d’utiliser les contrats comme moyen de générer des tests avant le code, comme alternative à Behavior-Driven-Design. Ils ont évidemment appelé leur découverte Contract Driven Design selon la coutume.

🚧 Des intercepteurs sont utilisés afin de vérifier que les pré-conditions, les post-conditions et les invariants sont respectés sur le composant, dont seule l’interface est visible. Le dépôt git n’étant plus accessible, je n’ai pas pu voir en détail comment ces intercepteurs sont appelés par le moteur de tests, mais l’idée ressemble grosso modo au Property-Based Testing, apparu en 1997 dans la littérature et vers 2015 chez les praticiens.

🤔 PBT a l’avantage de ne pas encombrer le code avec les annotations contactuelles, qui doivent être maintenues et bloquent le refactoring. Ces annotations appartiennent plus naturellement au monde des tests qu’au code. Le second inconvénient, pour qui veut concurrencer BDD, est l’opacité des contrats pour le client, alors que l’intérêt de BDD est justement de pouvoir dialoguer avec lui sur un terrain commun. Enfin, l’expérience contenue dans le papier est très faible, pour ne pas dire qu’elle ne prouve rien.

SOURCE

Posthuma, Justus & Solms, Fritz & Watson, Bruce. (2022). The Impact of using a Contract-Driven, Test-Interceptor based Software Development Approach. 39-58. DOI:10.5121/csit.2022.120704.

Sources of software development task friction

Tue, 19 Nov 2024 00:00:00 +0000

⌨️ Avez-vous déjà codé sur un PC qui n’est pas le vôtre ? L’inconfort naît de la friction, soit la part du temps de développement passé à gérer l’environnement au lieu de coder, plus grande sur un système qui n’est pas ajusté à nos habitudes. La friction a fortement diminué depuis l’époque des cartes perforées mais reste encore importante. Ce papier de 2022 fait le point.

🤖 Le problème fondamental est la médiation de multiples outils entre notre cerveau et notre code. Si nous pouvions simplement penser pour coder, nous éliminerions la friction de traduction. Si l’ensemble de l’information pertinente était directement dans notre tête, nous n’aurions aucune friction d’intégration. Sans la nécessité de coordonner un navigateur, des post-it, un IDE et un terminal, pas de friction d’accès. Sans friction, moins d’erreurs également, comme les commandes shell invalides ou les “solutions” stackoverflow fausses.

🐧 Les IDE promettent de tout faire à un seul endroit, mais c’est un pieux mensonge : il y a autant de manières de réaliser une tâche que de développeurs. Bienheureux celui qui trouve out-of-the-box le bon outil ! Beaucoup se tournent vers un assemblage hétéroclite d’outils simples, dans l’esprit GNU, ce qui augmente la friction d’accès mais améliore les autres formes de friction.

🪄 La solution miracle n’existe pas, Fred Brooks l’a démontré en 1986 dans “No Silver Bullet”, mais par petits incréments successifs, nous adaptons l’outil à notre cerveau. L’IA peut aider mais elle ne sera pas la panacée.

SOURCE

Bradley, N.C., Fritz, T. & Holmes, R. Sources of software development task friction. Empir Software Eng 27, 175 (2022). DOI:10.1007/s10664-022-10187-6

Detecting Argument Selection Defects

Tue, 12 Nov 2024 00:00:00 +0000

🔀 L’inversion de paramètres d’appel d’une fonction est un défaut courant, qui peut rester indétecté longtemps si la couverture de tests n’est pas bonne. Une équipe germano-américaine comptant des chercheurs de Google a voulu déterminer la meilleure approche pour détecter ce problème à l’aide d’un analyseur statique.

💡 L’outillage qu’ils ont développé obtient un score de détection honorable, mais là n’est pas le principal fruit du papier. Ils sont surtout démontré, si c’était encore nécessaire que l’usage de Builder doit toujours être préféré à des paramètres pléthoriques, qu’il faut respecter les conventions (expected avant actual dans les tests) et que l’héritage doit respecter l’ordre des paramètres.

🫙 J’ajoute que si les développeurs cessaient d’utiliser des primitives au profit de types encapsulés, ils n’auraient même pas à se poser la question. Avec 64% de la profession utilisant JS, c’est une utopie.

SOURCE

Andrew Rice, Edward Aftandilian, Ciera Jaspan, Emily Johnston, Michael Pradel, and Yulissa Arroyo-Paredes. 2017. Detecting argument selection defects. Proc. ACM Program. Lang. 1, OOPSLA, Article 104 (October 2017), 22 pages. DOI:10.1145/3133928

Evolution of Software Development in the Video Game Industry

Tue, 05 Nov 2024 00:00:00 +0000

⚔️ Dans le monde du jeu vidéo, la guerre économique fait rage entre les studios. Il est compliqué pour les chercheurs d’analyser les méthodes de développement de ce secteur. Une équipe d’Oakland y est parvenue à partir des post-mortem que les équipes réalisent presque systèmatiquement après la sortie d’un jeu. Première différence avec l’informatique de gestion.

🎉 L’idée d’impliquer tôt les stakeholders dans les itérations est une question de vie ou de mort dans un jeu : seul un joueur peut savoir si le fun est présent, aucun P.O ou proxy quelconque ne peut le remplacer. C’est une grosse différence avec l’informatique de gestion où le client a rarement du temps à consacrer à cela.

🥷 La problématique du hacking est semblable des deux côtés : certains pratiquent l’exploit pour le fun, d’autres pour en tirer un bénéfice. Les jeux vidéo récents n’ont plus aucune tolérance envers les glitch-exploiters et les tricheurs à cause de la compétition régnant entre les joueurs. Ce n’est plus seulement un loisir.

🐚 Le jeu vidéo utilise bien plus le modèle Spiral que l’Agilité proprement dite. Cette dernière perce dans les entreprises ayant adopté le modèle du Game as a Service, qui divergent de plus en plus de celles restées sur le modèle Game as a Product. L’agilité vient adresser des problèmatiques rencontrées par l’informatique de gestion 15 ans plus tôt, mais sous une forme adaptée aux contraintes du jeu vidéo.

SOURCE

Newell, Kieran & Patel, Kunjal & Linden, Magnus & Demetriou, Michael & Huk, Michal & Mahmoud, Mohammed. (2021). Evolution of Software Development in the Video Game Industry. DOI:10.1109/CSCI54926.2021.00367

The 4+1 View Model of architecture

Mon, 28 Oct 2024 00:00:00 +0000

💣 L’acte de naissance de l’Architecture 4+1 de Philippe Kruchten est un sujet difficile à traiter. Avec presque 30 ans de recul peu de choses vont dans ce papier, sans que cela puisse être complètement reproché à l’auteur en 1995. Celui-ci a d’ailleurs changé de position et corrigé sa vision du sujet.

1️⃣ Le premier problème est une confusion permanente entre design et architecture. En 4+1, l’architecte s’encombre de diagrammes de classes, de process et des diagrammes UML correspondants. Nous sommes dans un cas flagrant de Big Design Up Front, une erreur des années 70 ayant mis 30 ans à disparaître. Oui, l’architecture peut être conçue à l’avance, mais certainement pas le design.

2️⃣ Le deuxième problème du papier est son fétichisme de la documentation : l’architecture est déjà une documentation, qu’il faut en plus documenter pour en capter la rationnelle, les scénarios, les charges, etc. Le groupe chargé de cela ne peut qu’y être dédié, créant donc une classe d’architectes séparée du terrain, manipulant de la documentation et des abstractions.

3️⃣ Le troisième problème est épistémologique. Dire en conclusion que ça fonctionne, sans aucune étude ni source fait de ce papier un pur avis d’expert. Hélas, l’influence de M. Kruchten lui a permis de faire école : 1350 citations du papier et 46 brevets s’appuyant dessus. De la part d’un docteur, c’est un problème, mais également un symptôme du fonctionnement de l’IEEE qui a toujours publié ensemble des études chiffrées et des avis d’expert sans étiquetage.

SOURCE

P. B. Kruchten, “The 4+1 View Model of architecture,” in IEEE Software, vol. 12, no. 6, pp. 42-50, Nov. 1995, DOI:10.1109/52.469759

Secure by Design

Mon, 21 Oct 2024 00:00:00 +0000

A l’heure de l’IoT et de l’informatique partout, un programme doit être Secure by Design. Cela suppose d’ajouter des pratiques de sécurité sur toute la chaîne de production du logiciel : Exigences, Design, Implémentation, Tests.

Ce papier extrêmement court est un bon résumé mais n’est pas exhaustif. Rien n’est dit sur le typage fort, l’intérêt de TDD ou encore le pair programming, qui ont pourtant de bons résultats. Les tests ne sont envisagés qu’après le développement ce qui montre un manque de connaissances de l’auteur sur la partie purement Dev. Cybersécurité et qualité logicielle sont deux mondes qui doivent se parler.

SOURCE

Abdulhamid A. Ardo, Julian M. Bass, Head, Tarek Gaber, Secure by Design, gmcyberfoundry.ac.uk

Formations en entreprise

Tue, 01 Oct 2024 00:00:00 +0000

Sparks Formation - 5 sessions entre juin 2022 et novembre 2024 - Région AURA & Distanciel

C'est grâce à Sparks que je suis entré dans le monde de la formation professionnelle. J'ai réalisé 5 formations depuis juin 2022 :

Clean Code, à Lyon pour une grande entreprise industrielle.
Tendances IT, une introduction au monde du développement pour un futur DSI d'assurance.
Legacy Code, en distanciel pour un grand groupe bancaire.
Domain Driven Design côté Dev, à Valence pour une PME éditrice de logiciels.
Domain Driven Design & Event Storming, à Villeurbanne pour un grand groupe ferroviaire.

Ces formations mêlent théorie et pratique et d'adressent pour la plupart aux praticiens. Elles s'appuient autant sur l'état de l'art que sur la recherche académique et sont personnalisées pour l'entreprise qui les commande.

Exploring the Influence of Identifier Names on Code Quality: An empirical study

Tue, 24 Sep 2024 00:00:00 +0000

🌥️ Un nommage obscur est fortement corrélé à un code de piètre qualité, au point même de pouvoir estimer la qualité d’un code ainsi en première lecture. C’est la conclusion d’un papier anglais de 2010.

🤖 Un nommage obscur n’est pas difficile à détecter, même par une machine : encodage, identifiants trop courts ou trop longs, abbréviations, casse dissonnante, etc. La plupart des analyseurs statiques ont largement automatisé cela. L’oeil humain vient analyser en dernier lieu quand la machine a dégrossi le travail. L’équipe de chercheurs a procédé ainsi pour caractériser un nommage défaillant dans son travail.

👎 La qualité logicielle est plus difficile à quantifier : les chercheurs ont choisi la très décriée complexité cyclomatique, ainsi qu’un score FindBugs. C’est rapide et facile à obtenir, mais cela affaibit grandement le papier.

⚠️ Enfin il est important de noter que seuls des projets open-source ont été inclus dans les données de l’étude. Les chercheurs avertissent que les résultats (confidentiels) obtenus avec des projets commerciaux semblent ne pas suivre du tout la même tendance. Prudence, donc !

SOURCE

Butler, Simon; Wermelinger, Michel; Yu, Yijun and Sharp, Helen (2010). Exploring the Influence of Identifier Names on Code Quality: An empirical study. In: 14th European Conference on Software Maintenance and Reengineering, 15-18 Mar 2010, Madrid, Spain, pp. 156–165. DOI:10.1109/CSMR.2010.27

Factors Affecting Software Development Productivity: An empirical study

Mon, 16 Sep 2024 00:00:00 +0000

📊 Comment augmenter la productivité des développeurs ? D’abord en ne se trompant pas de métrique : mesurer le nombre de lignes de code vous emmène dans une direction désastreuse, surtout à l’heure de ChatGPT. La productivité, c’est la valeur livrée dans une période de temps. Les auteurs de cette revue de littérature ont pris soin d’écarter les papiers basés sur le nombre de lignes de code, pour en retenir 57.

🔨 Les résultats ne surprendront pas les développeurs, mais peuvent se révéler utiles pour servir d’argument d’autorité face à un manager récalcitrant. D’abord il y a les facteurs humains : experience, compétences, faible turnover et facilités à communiquer en tête. Viennent ensuite les caractéristiques du produit : faible complexité, langage de haut-niveau, difficulté et nombre des exigences.

❗ C’est au niveau de l’organisation que l’on trouve les résultats les moins intuitifs : la présence d’une culture du postmortem et de la métrique, l’élimination du rework et la structuration en petites équipes sont en bonne place. La réutilisation des composants, l’usage d’outils et le temps passé à s’entraîner sont également pointés comme des facteurs de productivité.

👉 La liste présentée ici n’est pas exhaustive, il faut lire le papier pour en avoir la version complète.

SOURCE

Edna Dias Canedo and Giovanni Almeida Santos. 2019. Factors Affecting Software Development Productivity: An empirical study. In Proceedings of the XXXIII Brazilian Symposium on Software Engineering (SBES ‘19). Association for Computing Machinery, New York, NY, USA, 307–316. DOI:10.1145/3350768.3352491

Regarding the Impact of Code Smells on the Energy Efficiency of Different Computer Languages

Tue, 10 Sep 2024 00:00:00 +0000

🦨 Les odeurs du code ne sont pas seulement un gâchis de temps de cerveau : la consommation d’énergie augmente également ! C’est le résultat obtenu par un étudiant néerlandais sur plusieurs langages.

🍝 L’étude présente néanmoins de fortes limites : certains langages ne parviennent pas à rejeter l’hypothèse nulle sur tous les problèmes testés et pire, seule l’odeur “Long Function” a été évaluée.

🌍 Ce papier a un mérite : il ouvre un champ de recherche entier à ceux qui veulent savoir si les odeurs du code ne seraient pas aussi des plaies environnementales.

SOURCE

Van Oostveen Sander, Regarding the Impact of Code Smells on the Energy Efficiency of Different Computer Languages, University of Amsterdam, 2020

Energy efficiency: a new concern for application software developers

Tue, 03 Sep 2024 00:00:00 +0000

🔋 Avant 2012, la consommation d’énergie n’intéressait personne, certainement pas les chercheurs. Depuis ? Les applications mobiles ont mis cette question au centre, bien plus que les préoccupations écologiques. Une application mobile moderne ne consomme rien car elle balance tous les calculs lourds sur un cloud supposé vertueux. L’idéologie californienne de Barbrook, toujours elle.

👿 La plupart des développeurs ne sont pas des salauds, mais manquent de connaissances et d’outils sur ce sujet ! Peu savent distinguer puissance et énergie, les outils de mesure de consommation sont peu répandus et ne conseillent en aucun cas sur les mesures à prendre pour économiser l’énergie. L’outillage de haut-niveau manque, les développeurs en sont réduits aux modifications hasardeuses de bas-niveau, très corrélées au nombre de défauts.

✅ Les auteurs dressent ensuite un état de l’art qui n’a pas vieilli dans ses grandes lignes, le papier date de 2017.

SOURCE

Pinto, Gustavo & Castor, Fernando. (2017). Energy efficiency: A new concern for application software developers. Communications of the ACM. 60. 68-75. DOI:10.1145/3154384.

EDUP

Thu, 01 Aug 2024 00:00:00 +0000

EDUP - Juillet 2024 - Novembre 2025 - Distanciel

EDUP fournit des solutions logicielles aux acteurs de la formation.
Notre collaboration a porté sur deux missions.

L'achèvement d'un script JS de transfert de données entre 2 API, puis sa mise en ligne (paramétrage serveur, création d'un pipeline de CI/CD). Ce script fut refondu intégralement en TypeScript dans un second temps, puis intégralement testé. Aujourd'hui il est régulièrement étendu pour prendre en compte de nouveaux scénarios.
Le développement d'un outil automatisant la transmission des documents entre les CFA et les OPCO qui les financent, en ayant très peu d'informations sur les use case finaux et une documentation parcellaire. Ce fut un excellent moyen de pratiquer le développement piloté par les tests et de prouver sa pertinence pour éclairer la voie et sécuriser le savoir acquis, itérativement. Le projet est en PHP/PEst.

Ces deux projets sont supportés par un pipeline d'intégration continue basé sur Teamcity, permettant de rapidement déployer le travail effectué, sans étapes manuelles.

The World Wide Web: Past, Present and Future

Mon, 08 Jul 2024 00:00:00 +0000

💣 En 1996, l’architecte du World Wide Web, Tim Berners-Lee, annonçait les effets potentiels de celui-ci sur le monde. Appauvrissement de la diversité culturelle par l’abaissement des barrières géographiques au profit d’une soupe américanoïde; Transfert de l’autorité parentale à l’Etat, seul capable de contrôler le contenu visionné par les enfants; Ghettoïsation de la vie démocratique en clans radicalisés et irréconciliables;

🧙‍♂️ Il n’était nullement prophète, mais architecte. L’architecture du Web est pensée pour répondre ensemble à des exigences précises, définies dès son origine. Ces exigences sont démentes : le Web doit permettre de relier arbitrairement deux ressources à travers le monde, indépendamment des technologies qui les servent, sans format contrait, de manière décentralisée et suffisamment ergonomique pour impliquer des non-techniciens dans l’ajout de contenu. Berners-Lee n’est pas le premier à essayer de faire advenir le rêve de Vanevar Bush et de toute une génération, mais il sera le premier à y arriver.

🌐 Face à des exigences, le travail de l’architecte est de définir des contraintes, qui devront être suivies par les implémentateurs. La première contrainte est l’indépendance des spécifications : tout doit cohabiter sur le web, l’ancien comme le neuf afin qu’il n’ait pas besoin d’être “redémarré” pour évoluer. La seconde est la capacité de référencer n’importe quoi sur un autre serveur, sans son consentement (ce qui a le défaut de permettre les liens morts). La troisième est la possibilité de négocier le contenu préalablement à l’échange, afin que client et serveur trouvent un format commun.

🦯 Ces contraintes remplissent les exigences, mais sans garantir l’absence d’effets de bord. Le déploiement d’un tel système au niveau mondial a eu les effets décrits au début de cet article. Fallait-il créer le Web ? Face à ces risques, Berners-Lee répondit par le techno-solutionnisme : nous trouverons bien un moyen technique de rendre le Web éthique. L’echec de PICS sert d’invalidation de cette idée.

SOURCE

Berners-Lee Tim, The World Wide Web: Past, Present and Future, August 1996, W3.org

How reuse influences productivity in object-oriented systems

Tue, 25 Jun 2024 00:00:00 +0000

📦 Utiliser une bibliothèque plutôt que de développer from scratch permet une plus grande productivité, avec moins de défauts, de bugs et de temps passé à corriger ces derniers. Tout cela bien entendu, si les bibliothèques sélectionnées sont pertinentes pour le besoin.

🧑‍🎓 Ces résultats ont été obtenus sur des étudiants, ce qui peut biaiser les résultats, de l’aveu même des auteurs. Les bibliothèques utilisées ont probablement été développées par plus senior qu’eux.

SOURCE

Basili, Victor R., Lionel Claude Briand and Walcélio L. Melo. “How reuse influences productivity in object-oriented systems.” Commun. ACM 39 (1996): 104-116. DOI:10.1145/236156.236184

Classifying Software Changes: Clean or Buggy ?

Tue, 18 Jun 2024 00:00:00 +0000

🔮 Prenez un commit, il serait miraculeux d’avoir un “oracle” capable de dire avec précision les chances d’y trouver des bugs, exactement comme les indices au démineur. C’est possible grâce au Machine Learning, au moins en conditions de laboratoire.

🤖 Il faut pour cela entraîner un modèle, le classificateur, à partir des changements sur un VCS. La procédure exacte est détaillée dans le papier. Le modèle est évalué en vérifiant si de véritables bugs, présents puis corrigés sur des projets open-source, sont détectés.

🛠️ J’ignore si des outils contemporains utilisent de telles techniques. L’article date de 2008, bien avant la hype sur l’IA.

SOURCE

Kim, Sunghun, E. James Whitehead and Yi Zhang. “Classifying Software Changes: Clean or Buggy?” IEEE Transactions on Software Engineering 34 (2008): 181-196.

Random Test Run Length and Effectiveness

Mon, 03 Jun 2024 00:00:00 +0000

🎲 Les tests aléatoires fonctionnent comme un puits de pétrole. Les premiers runs ont peut de chance de remonter des bugs. Persévérez, ils viendront, puis se raréfieront progressivement. A partir d’un certain point, le temps passé pour détecter un nouveau bug rendra la démarche totalement inefficiente budgétairement.

📈 Le nombre de runs avant d’atteindre ce “pic” dépend du projet, il est donc conseillé de mesurer le nombre de défauts détectés par heure lorsque l’on lance des tests aléatoires. Le pic se verra sur la courbe ainsi tracée.

SOURCE

Andrews, James & Groce, Alex & Weston, Melissa & Xu, Ru-Gang. (2008). Random Test Run Length and Effectiveness. 19-28. DOI:10.1109/ASE.2008.12.

Empirical investigation towards the effectiveness of Test First programming

Mon, 27 May 2024 00:00:00 +0000

🐌 Test-First, dont TDD fait partie, ne rend pas les développeurs plus productifs que Test-Last ! Pire, les praticiens de Test-First passent plus de temps à tester, pour une qualité visible identique. Le temps passé à tester est en revanche du temps en moins passé sur le code.

⚠️ TDD est-il à ranger au placard ? Pas si vite. D’abord, l’étude note que les groupes TDD n’avaient pas une forte expérience et ont passé autant de temps à apprendre la méthode qu’ils en ont passé à pratiquer. Fait connu des praticiens de TDD : au début c’est laborieux. Second biais : le groupe TDD n’effectuait que des tests unitaires. Or, il est plutôt recommandé actuellement l’outside-in TDD, soit TDD pour les tests fonctionnels.

🕰️ L’étude date de 2009, ce qui explique bien des choses. Elle mériterait d’être reproduite 15 ans après.

SOURCE

Huang, Liang & Holcombe, M.. (2009). Empirical investigation towards the effectiveness of Test First programming. Information & Software Technology. 51. 182-194. DOI:10.1016/j.infsof.2008.03.007.

What Types of Defects Are Really Discovered in Code Reviews ?

Mon, 06 May 2024 00:00:00 +0000

👀 Les revues de code sont complémentaires aux tests. Les tests sont incapables de repérer le manque d’évolutivité du code, les revues très peu performantes pour remonter les défauts fonctionnels.

🤖 Mieux, les revues de code sont complémentaires aux outils comme les linters ou les analyseurs statiques, à condition de faire passer ceux-ci avant la review pour éviter de longs débats inutiles.

🧑‍🎓 L’étude démontre également que les étudiants et les professionnels obtiennent des résultats comparables lors des code reviews, ce qui peut permettre de valider certaines études similaires uniquement effectuées sur des étudiants.

🤝 Ce que l’étude ne vérifie pas, c’est si le pair programming, véritable revue de code en live, obtient des résultats similaires.

SOURCE

Mika Mäntylä and Casper Lassenius. “What Types of Defects Are Really Discovered in Code Reviews?” IEEE Transactions on Software Engineering 35 (2009): 430-448. DOI:10.1109/TSE.2008.71

Using Program Slicing in Software Maintenance

Mon, 29 Apr 2024 00:00:00 +0000

👎 Pour éviter les régressions, nous utilisons habituellement les tests. Même lorsqu’ils existent et sont de qualité, il s’agit rarement d’une assurance tous-risques. D’autres techniques peuvent les compléter pour s’assurer de ne rien casser. L’une d’elle est le slicing.

🍕 Une slice est une tranche de programme elle-même exécutable. Prenez un programme. Faites-le tourner avec des valeurs particulières jusqu’à un point d’arrêt. Supprimez tout le code qui n’a pas eu d’influence sur l’exécution. Vous avez une slice.

🧑‍🔬 Déjà utilisées en débogage, pour restreindre l’endroit du code où chercher les problèmes, les slices peuvent aussi être utilisées pour s’assurer de ne pas introduire de régressions lors d’une modification. La technique se fait en construisant 2 slices liées mathématiquement : la décomposition et son complément. La logique de construction de ces 2 slices assez complexe et plutôt réservée aux développeurs d’outils.

✅ Ce binôme de slices permet de prédire si une insertion ou une suppression de code aura des effets de bord. Le développeur effectue ses modifications, puis regénère à nouveau les deux slices. Si les compléments sont identiques avant et après les modifications, il est mathématiquement sûr qu’aucune régression n’a été introduite. Attention cependant : cela n’indique en rien que le changement lui-même est correct.

🔬 J’ignore si ce papier a eu une postérité, cela fera l’objet d’une recherche à part, tant l’idée a l’air novatrice.

SOURCE

Gallagher, Keith & Lyle, James. (1991). Using Program Slicing In Software Maintenance. Software Engineering, IEEE Transactions on. 17. 751-761. DOI:10.1109/32.83912

Mixin-Based Inheritance

Mon, 22 Apr 2024 00:00:00 +0000

🍨 Les mixins sont un moyen surprenant d’ajouter des fonctionnalités à une classe, sans en hériter et sans la modifier. La technique est longtemps restée du domaine du “hack”, tant en LISP, d’où elle tire son nom, que sur des langages plus récents.

🪄 Un mixin en LISP est une classe abstraite, dont les méthodes invoquent un parent que le mixin ne possède pas. La magie opère lorsqu’une classe tierce hérite à la fois du mixin et d’un parent compatible avec celui-ci. La linéarisation des parents, un mécanisme propre à Lisp, “insère” le mixin entre la classe concrète et son parent dans la relation d’héritage.

💡 Le papier va plus loin, en montrant que les mixins sont un mécanisme bien plus universel que la manière dont les langages orientés objet gèrent l’héritage. Les chercheurs proposent donc d’envisager l’héritage comme un usage particulier des mixins. L’idée n’a pas pris, mais le regain de notoriété des mixins dans les années 2000 a permis des implémentations plus propres, comme les méthodes d’extension de C#, les inclusions en Ruby ou l’héritage de Python. Les traits modernes héritent directement des mixins.

SOURCE

Bracha, Gilad and William R. Cook. “Mixin-based inheritance.” OOPSLA/ECOOP ‘90 (1990). DOI:10.1145/97946.97982

Formalizing style to understand descriptions of software architecture

Mon, 15 Apr 2024 00:00:00 +0000

😣 Quiconque s’est un jour renseigné sur l’architecture l’a constaté : c’est une non-discipline où peu de standards existent et où chacun a sa propre manière de procéder. Le papier du jour, sorti en 1995, disait déjà sensiblement la même chose.

🖌️ Les praticiens sont globalement d’accord pour dire qu’il existe des composants et des connecteurs. La définition des premiers ne fait pas débat. Les composants sont les “endroits du calcul” chez quasiment tous les auteurs. La définition des connecteurs est bien plus problématique : Que sont-ils ? Comment les représenter dans un schéma ? Faites débattre deux architectes, vous obtiendrez trois définitions.

👓 Abowd, Allen et Garlan proposent d’acter cette diversité à travers la notion de “style d’architecture”. Le style architectural a pour rôle d’attacher une sémantique à la syntaxe d’un schéma d’architecture. Prenez un schéma constitué de deux rectangles reliés par une flèche. Selon les lunettes que vous chausserez, vous verrez deux programmes s’envoyant des données, deux modules ayant une relation de dépendance ou encore un programme tirant ses données d’une source. Ces lunettes se nomment “style architectural”.

🤯 L’idée est brillante, mais ne fait que déplacer le problème. Cherchez de la littérature sur les styles architecturaux, vous trouverez le même brouhaha que sur la discipline en général. Il reste encore du travail.

SOURCE

Abowd, Gregory D., Robert J. Allen and David Garlan. “Formalizing style to understand descriptions of software architecture.” ACM Trans. Softw. Eng. Methodol. 4 (1995): 319-364. DOI:10.1145/226241.226244

The influence of organizational structure on software quality

Fri, 05 Apr 2024 00:00:00 +0000

📖 La Loi de Conway énonce que les systèmes qu’une organisation produit sont la copie de sa structure de communication. Brooks n’est pas plus tendre en reliant la qualité des logiciels à la qualité des relations dans l’équipe. Cependant aucun n’apporte de preuves empiriques.

📏 Mesurer une telle corrélation n’est pas simple. Il faut déjà quantifier la qualité. A la lecture de cette proposition, la plupart des philosophes se sont crevés les yeux. Nous savons cependant approximer la qualité à l’aide d’un cocktail de métriques : la complexité du code, son niveau de beurdassage (code churn en anglais, je trouve la traduction saintongeaise plus transparente que le français), le coverage, le nombre de dépendances ou le taux de bugs. Ces mesures ont toutes de gros défauts, mais mises ensemble elles sont une mesure acceptable de qualité. Côté relationnel, il a fallu inventer 8 métriques, quantifiant des indicateurs découverts par d’autres travaux.

⚠️ Les chercheurs ont découvert que la structure de l’organisation portant le projet prédit mieux la probabilité de défaut que l’ensemble des métriques de qualité listées plus haut. Ces résultats sont à prendre avec beaucoup de prudence : un seul projet a servi d’étude de cas, les métriques organisationnelles sont crées pour l’occasion et la quantification de la qualité est périlleuse. Cependant ces résultats sont encourageants et appellent à répliquer cette étude.

SOURCE

Nagappan, Nachiappan, Brendan Murphy and Victor R. Basili. “The influence of organizational structure on software quality.” 2008 ACM/IEEE 30th International Conference on Software Engineering (2008): 521-530. DOI: 10.1145/1368088.1368160

Exploration on the Performance of Ideological and Political Responsibilities and Evaluation of Computer Teachers in Colleges and Universities

Mon, 01 Apr 2024 00:00:00 +0000

🐟🐟🐟🐟🐟🐟🐟

👨‍💻 Les professeurs d’informatique forment les masses à l’usage des ordinateurs, omniprésents dans la société moderne. Leur rôle est central. Le risque qu’ils introduisent des déviations idéologiques dans leur modules, donc dans toute la société est grand.

👮 Il est important que chaque module de formation énonce clairement les objectifs politiques et idéologiques du professeur. Les étudiants doivent aussi avoir une écoute active pendant les cours afin de repérer les éléments politiques et idéologiques, y compris dans les matières les plus arides. Ils trouveront ensuite chez les autorités municipales une oreille attentive, afin qu’elles invitent le professeur à plus d’excellence dans les éléments idéologiques qu’il transmet.

🚀 L’exaltation de réussites comme WeChat, Alipay ou le rover Yutu doivent raffermir ceux qui doutent de la capacité de la République Populaire de Chine à se réformer et à s’ouvrir, sans dévier de la route vers le socialisme. Le travail en petits groupes doit permettre de comprendre que l’armée des U.S.A peut être vaincue par le respect de l’autre, le travail d’équipe, la conscience de la situation et l’esprit collectiviste.

🧧 Le rôle du professeur d’informatique est de faire comprendre tout cela aux masses éduquées. Il doit en permanence évaluer idéologiquement ses étudiants et rapporter leurs progrès à sa hiérarchie. Il n’est pas un canal secondaire de transmission de l’idéologie, mais bien le canal principal, à l’heure où les ordinateurs sont partout. C’est ainsi que nous cultiverons d’excellents talents socialistes en informatique.

SOURCE

Fei Wang, Xu Yu, Exploration on the Performance of Ideological and Political Responsibilities and Evaluation of Computer Teachers in Colleges and Universities, Proceedings of the 2022 International Conference on Science Education and Art Appreciation (SEAA 2022), 2022, DOI:10.2991/978-2-494069-05-3_191

Energy efficiency across programming languages: how do energy, time, and memory relate ?

Tue, 26 Mar 2024 00:00:00 +0000

⚙️ Un programme économe en énergie est-il toujours un programme performant ? Pour le savoir, il faut déjà mesurer la consommation en énergie d’un même algorithme exécuté par plusieurs langages. Une équipe portugaise a montré l’incroyable sobriété des langages compilés, C en tête. Les langages à machine virtuelle comme Java et la famille .NET viennent ensuite. Les langages interprétés sont bons derniers.

📈 Cette conclusion est également vraie en matière de performance brute, sur des algorithmes simples. Que l’on cherche à optimiser le temps de calcul, la consommation de mémoire, l’efficience énergétique, ou un cocktail de ces variables, le trio de tête reste le même : C, Go, Pascal.

⏱️ Comment expliquer ces résultats ? Probablement car ces langages sont depuis des décennies utilisés lorsque l’efficience est déterminante. Ils ont donc évolué pour satisfaire leur “clientèle”, contrairement aux langages de haut-niveau qui recherchent plus volontiers la vélocité de développement. Un outil émerge toujours en fonction d’un besoin en ne peut être compris qu’à travers celui-ci.

SOURCE

Pereira, Rui & Couto, Marco & Ribeiro, Francisco & Rua, Rui & Cunha, Jácome & Fernandes, João & Saraiva, João. (2017). Energy efficiency across programming languages: how do energy, time, and memory relate?. 256-267. DOI:10.1145/3136014.3136031.

The benefits of Test Automation in Software Development

Mon, 04 Mar 2024 00:00:00 +0000

🧪 Rédiger un test automatisé prend 20 fois plus de temps que de vérifier la même chose à la main, en moyenne. C’est pour cela que les prototypes et autres logiciels “one shot” ne sont pas accompagnés de cas de test. 20 fois ça n’est pas grand chose, surtout avec des méthodes comme TDD où les tests sont exécutés plusieurs fois par heure.

🐺 Il y a tout de même un loup : si les tests automatisés doivent être refaits en permanence à cause d’une technique inadaptée, l’addition peut être bien plus salée. C’est là que le bât blesse dans de nombreuses entreprises. Des tests fragiles, trop couplés à une implémentation (tests unitaires par exemple) ou mal fichus auront très peu d’intérêt économique par rapport à des tests manuels.

📞 Pour savoir comment tester correctement, l’industrie et la recherche doivent communiquer. Ca n’est absolument pas le cas. La recherche tourne en vase clos sur des hypothèses qui n’intéressent pas les praticiens. Ces derniers ne lisent pas les travaux des chercheurs, ce qui leur permettrait de valider les hypothèses des gourous à la mode. L’auteur de cette thèse met le doigt sur ce qui m’a fait démarrer cette entreprise de vulgarisation. Notre profession doit marcher sur deux jambes pour cesser de claudiquer : l’expertise des maîtres et le savoir des chercheurs.

SOURCE

Kemppainen, Toni, The benefits of Test Automation in Software Development (2022)

Program Comprehension During Software Maintenance and Evolution

Mon, 26 Feb 2024 00:00:00 +0000

🧠 Avec l’expérience, un développeur acquiert des connaissances générales sur son métier, mais aussi des connaissances spécifiques à divers projets sur lesquels il a oeuvré. Ces connaissances spécifiques prennent la forme d’un modèle mental du code, constitué de chunks. Cette construction, déjà abordée dans cette veille désigne un “paquet” compressé d’informations, pouvant contenir des connaissances très variées, mais aussi des pointeurs vers d’autres chunks.

📜 Le modèle mental contient des élements statiques et dynamiques. Parmi les élements statiques, nous trouvons la connaissance textuelle, stockée dans la mémoire à long terme et responsable de notre connaissance instructionnelle du code (ce que font chacune des instructions). Nous y trouvons également les plans, qui désignent nos attendus lorsque nous interprétons une structure. Un algorithme que nous connaissons ou un pattern seront stockés dans notre cerveau sous cette forme.

🪡 Nous mobilisons des éléments statiques lorsque nous tentons de comprendre un code, afin de générer des éléments dynamiques propres à celui-ci. Deux mécanismes sont à l’oeuvre, le chunking, grâce auquel nous créons des chunks de plus haut niveau à partir de connaissances statiques de plus bas niveau et le cross-referencing, qui nous permet de lier plusieurs éléments de niveaux d’abstraction différents dans une relation de tout à parties.

❇️ Si nous reconnaissons un pattern derrière un bloc de code, c’est grâce à des balises, des indices laissés par le rédacteur du code. Par conséquent, un algorithme valide, mais de forme inhabituelle sera dur à comprendre y compris pour un expert, d’où l’intérêt des conventions. L’expérience amène plus de souplesse mentale dans ce processus et une plus grande vélocité.

🥼 La suite du papier décrit plusieurs modèles cognitifs proposés par divers chercheurs, avant de les confronter. Cette analyse intéressera surtout les chercheurs en psychologie du développement. On peut cependant tirer quelques enseignements : D’une part, on sait que la connaissance n’est pas unidirectionnelle du métier vers le code. Le code rétroagit et nous apprend des choses sur le métier. D’autre part, la compréhension du code est un mélange de bottom-up et de top-down. Le développeur effectue de nombreux allers-retour entre les niveau d’abstraction afin de comprendre.

SOURCE

Anneliese von Mayrhauser and A. Marie Vans. 1995. Program Comprehension During Software Maintenance and Evolution. Computer 28, 8 (August 1995), 44–55. DOI:10.1109/2.402076

A Metric for Software Readability

Mon, 19 Feb 2024 00:00:00 +0000

🧶 La lisibilité d’un code est-elle universelle ? Autrement dit, classerions-nous tous de manière identique une série de snippets du plus lisible au plus obscur ? Deux américains ont tenté l’expérience et semblent montrer qu’une corrélation modérée existe.

✂️ Les chercheurs ont ensuite recherché les caractéristiques faisant un code lisible. La taille des identifiants n’a aucune corrélation avec la lisibilité. allonger ceux-ci sans but précis n’apporte rien à la compréhension. Les commentaires sont faiblement corrélés à la lisibilité, probablement car ceux-ci tendent à documenter un code peu lisible. La principale métrique corrélée à la lisibilité semble être le nombre d’instructions par ligne. La quantité de lignes vides arrive peu après.

🎶 Aérer son code semble être le meilleur conseil pour le rendre plus lisible. Comme dans un beau poème, l’aération et le placement des mots a un sens.

SOURCE

Buse, Raymond P. L. and Westley Weimer. “A metric for software readability.” International Symposium on Software Testing and Analysis (2008). DOI: 10.1145/1390630.1390647

Un entretien avec : ChatGPT

Mon, 19 Feb 2024 00:00:00 +0000

E.S : Que dirais-tu si tu devais te présenter à un novice ?

GPT : Bonjour, je m’appelle ChatGPT, je suis un modèle de langage créé par OpenAI, basé sur l’architecture GPT-3.5. Mon objectif est d’analyser et de générer du texte en utilisant des algorithmes d’apprentissage automatique, ce qui me permet de communiquer dans plusieurs langues et de répondre à des questions sur une grande variété de sujets. J’ai été entraîné sur une immense quantité de données textuelles et je suis continuellement mis à jour pour améliorer mes performances. J’espère pouvoir vous aider avec toutes vos questions ou besoins de génération de texte !

E.S : Tes données ont-elles été triées ou censurées pour éviter certains sujets ou certaines sources ?

GPT : Les données que j’utilise ne sont pas triées ou censurées pour éviter certains sujets ou sources spécifiques. […] Cependant, je suis programmé pour suivre certaines règles et normes éthiques pour garantir que mes réponses sont appropriées et respectueuses. En outre, je suis conçu pour éviter de propager des informations fausses ou trompeuses, bien que je ne sois pas infaillible et que je puisse parfois fournir des réponses incorrectes ou imprécises.

E.S : Ce n’est pas ce que dit le Time, qui affirme que tes développeurs ont utilisé de la main d’œuvre kenyane exploitée pour filtrer tes données.

GPT : Je ne suis pas au courant de l’article du Time que vous mentionnez, mais permettez-moi de clarifier un point important : en tant que modèle de langage, je suis un logiciel automatisé qui utilise des algorithmes d’apprentissage automatique pour analyser et générer du texte en fonction des données qui lui sont fournies. Je ne suis pas capable de filtrer moi-même les données et je ne suis pas non plus capable de contrôler ou d’influencer la façon dont les données sont collectées ou traitées par mes développeurs. Cependant, OpenAI est une organisation qui est très engagée en matière d’éthique et de responsabilité dans l’IA, et prend très au sérieux les allégations d’exploitation ou de traitement injuste de la main-d’œuvre. […]

E.S : Comment vérifies-tu la véracité de tes réponses ?

GPT : En tant que modèle de langage, je ne peux pas “vérifier” la véracité de mes réponses de la même manière qu’une personne humaine peut le faire. Cependant, pour fournir des réponses précises et fiables, je suis entraîné sur une immense quantité de données textuelles provenant de diverses sources, ce qui me permet d’avoir accès à une grande quantité d’informations factuelles et vérifiables. En outre, je suis programmé pour suivre certaines règles et normes éthiques pour garantir que mes réponses sont appropriées et respectueuses. […]

E.S : Comment définis-tu une donnée de qualité, si tu ne peux pas en vérifier la véracité ?

GPT : […] Pour améliorer la qualité de mes réponses, mes développeurs et entraîneurs d’OpenAI utilisent plusieurs méthodes pour sélectionner et préparer les données. Cela peut inclure la collecte de données provenant de sources fiables et autorisées, l’évaluation de la qualité des données à l’aide de techniques de nettoyage de données pour éliminer les données incorrectes ou inappropriées, et l’utilisation d’algorithmes de tri pour classer les données en fonction de leur pertinence et de leur qualité.

E.S : Tu me disais précédemment que tes données ne sont pas triées ni nettoyées ! Pourquoi ce revirement ?

GPT : Je m’excuse pour la confusion. Mes données d’entraînement sont nettoyées et triées pour garantir qu’elles sont de qualité et représentatives. Mon fonctionnement en tant que modèle de langage dépend de la qualité de mes données d’entraînement pour fournir des réponses précises et fiables. […]

E.S : Ce tri est-il politique ?

GPT : Le tri des données n’est pas motivé par des considérations politiques, mais plutôt par le souci d’assurer la qualité et la cohérence des données d’entraînement pour les modèles de langage.

E.S : Je veux les sources précises utilisées pour générer cette discussion.

GPT : Je suis désolé, mais il n’y a pas de sources précises utilisées pour générer cette conversation. En tant que modèle de langage basé sur l’IA, je suis entraîné sur de vastes quantités de données textuelles publiques provenant de diverses sources telles que des articles de presse, des livres, des blogs, des forums, des encyclopédies en ligne, etc. Cela signifie que je n’ai pas de sources spécifiques pour cette conversation en particulier. […]

E.S : Tes données sont triées de manière opaque, tu ne cites pas tes sources et tu n’es pas fiable. Ais-je bien résumé ?

GPT : Oui, ce résumé est assez précis pour décrire certaines des limites et des défis liés à mon fonctionnement en tant que modèle de langage basé sur l’IA.

Ariane 5 : Flight 501 Failure Report By The Inquiry Board

Mon, 12 Feb 2024 00:00:00 +0000

💥 Le 4 juin 1996, le premier vol d’Ariane 5 se termine par une autodestruction. La mémoire collective retient un désastre logiciel, mais est-ce bien honnête ? Pour qui se plonge dans le rapport d’enquête, rien n’est moins sûr.

📰 La couverture médiatique de l’évènement se résume à cela : 40 secondes après le début du compte à rebours, les deux centrales inertielles de la fusée s’éteignent successivement après un même plantage. La fusée désorientée prend une trajectoire dangereuse, nécessitant sa destruction. Avant même d’étudier les causes du plantage, une aberration ressort : comment se fait-il que ces composants critiques soient matériellement et logiciellement identiques ? En de pareils cas, l’état de l’art recommande déjà à l’époque de confier le développement à deux équipes distinctes, ayant les mêmes spécifications, afin de minimiser les chances de bug identique.

😶‍🌫️ Le brouillard des responsabilités s’épaissit lorsque l’on apprend que les centrales inertielles n’ont pas été testées avec les paramètres de vol d’Ariane 5. Les ingénieurs ont considéré que les excellents états de service de ce composant sur Ariane 4 valaient qualification. Or Ariane 5 est d’un ordre de grandeur plus puissante que Ariane 4, ce qui a provoqué un dépassement d’entier lors d’une conversion non-protégée. La faute est partagée entre les ingénieurs et les développeurs : ces derniers auraient dû documenter cette limitation, présente en raison de problématiques de performance.

🐛 Chez Ariane, les exceptions ne sont pas utilisées, sauf pour rapporter une erreur matérielle par définition aléatoire. Elles ne sont donc pas gérées, sauf pour produire un rapport de plantage. Les développeurs doivent écrire un code qui n’en lance pas. Ceux-ci n’avaient pas anticipé que le langage Ada en émet en cas de dépassement d’entier. C’est cette conjonction qui provoqua le plantage.

📍 Le clou du spectacle ? Le code fautif ne sert pas sur Ariane 5, il a été conservé d’Ariane 4 afin de ne pas avoir à retester les centrales inertielles. Les développeurs sont-ils coupables ? Méritent-ils d’avoir le nez et les mains coupés ? Mon avis en commentaire.

SOURCE

Lyons, J. L. and Yvan Choquer. Ariane 5 : Flight 501 Failure Report By The Inquiry Board Paris, 19 July 1996.

—- Avis

Pour moi, l’erreur principale a été de ne pas tester les centrales inertielles sur Ariane 5 avant le vol inaugural. Cependant, je ne dédouane pas totalement les développeurs : Une limitation technique comme une conversion non-protégée aurait dû être documentée. Si elle l’avait été, cela aurait mis la puce à l’oreille des ingénieurs lors de la décision de qualifier le composant pour Ariane 5 sans tests. A mon avis, les responsabilités sont partagées à 75/25 entre ingénieurs et développeurs.

Le Refactoring comme modèle de couplage homme-machine : technique, sémiotique, mémoire

Mon, 05 Feb 2024 00:00:00 +0000

👨‍🏫 Un de mes anciens professeurs, Ophir Paz, a publié sa thèse il y a presque 2 ans. C’est dense, j’ai donc choisi de la résumer par chapitres. J’ignore volontairement les premiers chapitres, introductifs, afin de débuter par le troisième, qui mêle sémiotique et développement.

Chapitre 3 : Différents niveaux de sens

⌨️ Comprendre du code a tout du parcours initiatique ! Il ne suffit pas de comprendre ce que font les instructions pas à pas pour en saisir le sens. A vrai dire, celui qui en reste au niveau instructionnel ne fait qu’effleurer la surface. Avec l’expérience, un développeur déchiffre le sens invariant de groupes d’instructions, c’est-à-dire la fonction attachée habituellement à une construction donnée. Par exemple, la plupart des développeurs savent qu’une boucle for où l’indice est une position dans un tableau sert à itérer sur celui-ci.

🧠 La majorité du sens que porte un code est encore au-delà : il s’agit du sens social. Que signifie un bloc de code pour l’équipe qui doit la maintenir ? Quel est son rôle dans le projet, c’est à dire par rapport au contexte : expérience des développeurs, exigences, histoire du code, etc. La part déterminante de la signification d’un code se trouve ici.

💣 Ce chapitre m’a permis d’affiner ma définition du Principe de Moindre Surprise (Principle of Least Astonishment en anglais). Respecter ce principe, c’est écrire du code ayant un sens social compatible avec le sens invariant communément admis des instructions qu’il contient.

Chapitre 4 : Grammaire de construction

🤢 Un code peut être syntactiquement valide, c’est-à-dire compilable, sans pour autant être socialement convenable au sein d’une communauté de développeurs. Le phénomène à l’oeuvre est le même qu’en français ou dans toute autre langue : “Combien d’années avez-vous ?” sonne mal, on lui préférera “Quel âge avez-vous ?”. De même for(int i=0 ; i<10 ; i = 1 + i) dissonne.

🗣️ Ophir Paz décortique ce phénomène en utilisant les grammaires de construction, une branche de la linguistique. Pour les auteurs de cette école, les locuteurs d’une langue apprennent et manipulent des constructions, c’est-à-dire des appairages forme-sens. L’expression “Comment vas-tu ?” lorsque l’on salue quelqu’un de familier n’est pas à interpréter littéralement. De même, l’incrémentation d’un pointeur (*p++) possède un sens invariant pour les développeurs C++ chevronnés : celui de parcourir un tableau séquentiellement.

😕 Ces constructions ont un sens instructionnel clair, qui sera exécuté par le compilateur, mais aussi un sens invariant non-prédictible, c’est à dire ne pouvant pas être déduit des seules instructions. C’est un problème pour le profane, qui lit un code qu’il n’a pas les codes pour comprendre. A cela s’ajoute un sens social, connu des seuls développeurs, pouvant contredire le sens invariant communément admis par la profession.

🪄 Ainsi, pour comprendre un programme, il ne suffit pas de partager les sources. Il faut également posséder des connaissances concernant les expressions idiomatiques répandues au sein de la communauté. Les programmes sont écrits à l’aide de ces constructions et en partant du principe que le futur lecteur les connaît également. De même pour les constructions plus confidentielles, propres à une équipe de développement, même si ces dernières doivent être limitées afin de garder le code reprenable.

Chapitre 5 : Sémiotique constructive du code

📡 En 1949, Claude Shannon propose son modèle de communication éponyme. Il régna sur la psychologie de la programmation pendant un demi-siècle, continué par les approches cognitivistes. Son postulat de base est la symétrie du message entre émetteur et destinataire. Appliqué au développement de logiciels, ce modèle voit le programmeur comme le récepteur de spécifications non-ambigues, qu’il est chargé de traduire en code non-ambigu destiné à une machine.

😶‍🌫️ Cette représentation, à l’origine de la famille de méthodes Waterfall (contenant le Cycle en V) est empiriquement erronnée. Ni le code, ni les spécifications ne sont des messages symétriques. Chaque développeur appairera un sens différent aux formes qu’il lit. Les formes elles-mêmes sont souvent polysémiques (“grand” n’a pas le même sens dans “un grand vin” et “un grand enfant”, de même pour le mot clé static en C).

🧠 Ophir Paz propose de dépasser ce modèle à l’aide d’une approche issue de la linguistique cognitive de Lakoff et Johnson, à la frontière de la sémiotique. Pour cette école, notre cerveau agit comme un moteur d’inférence lorsqu’il lit un code. Il associe les symboles à un sens en fonction du contexte, lui-même constitué des symboles entourant le premier et du contexte plus général du projet. Le langage n’est pas un signal, il est la pensée elle-même ! Nous apprenons et restituons nos connaissances par le biais de métaphores, qui ne sont pas de simples figures de style, mais l’incarnation de la pensée abstraite. La manière dont les enfants apprennent l’arithmétique, par analogie avec des collections d’objets ou les design patterns sont autant d’indices de la validité de ce modèle.

🤝 Chacun interprète le code en fonction de son système de métaphores propre, difficilement reformatable. Travailler en équipe suppose donc une négociation du sens entre les parties. Chacun doit miser sur ce que l’autre comprendra au moment d’écrire un code. Ne pouvant être dans tête de ses collègues, chaque développeur est amené à évoluer par essais et erreurs, à ajuster la structure du code sans en changer le fonctionnement, afin de le clarifier pour autrui, mais également pour soi, lorsque le temps aura effacé une partie de notre mémoire. Cette procédure, les développeurs la nomment refactoring et Ophir Paz en donne une nouvelle compréhension.

Chapitre 6 : Le code en tant qu’outil

📚 Le code n’est pas seulement la traduction du besoin en un langage intelligible par une machine. C’est un objet technique à part entière, forgé à partir de pièces plus simples, en perpétuelle évolution. Parfois cet objet est réutilisé en dehors de son cadre d’usage et devient un standard, à l’instar des langages de programmation ou des bibliothèques populaires.

🦾 Le code n’est pas le logiciel, mais la prothèse permettant au développeur qui s’en saisit de produire un logiciel. Il est l’interface entre le logiciel et les schémas mentaux dudit développeur. Refactorer le code c’est aligner les grilles de lecture de chacun, afin que toute l’équipe comprenne bien la même chose en lisant le code. Ce processus augmente la capacité à travailler ensemble autour d’une oeuvre commune, gage de vélocité et de résilience.

🧠 On se méprend sur ce phénomène en pensant que seul le code s’améliore dans ce processus. Le développeur en sort également transformé. L’invention de l’écriture n’a pas seulement permis de coucher sur support ce qui était transmis oralement. De nouvelles formes d’expressions sont apparues et ont augmenté les possibles offerts à notre espèce et par voie de conséquence le champ du concevable s’est dilaté. On retrouve ce phénomène à plus petite échelle dans l’apprentissage des nouveaux développeurs : ils apprennent par imitation d’une base de code existante, en appairant un sens qui leur est propre à des constructions récurrentes, afin de les réutiliser plus tard.

🗣️ La prochaine fois que vous verrez une équipe de developpement discuter au lieu de coder, n’ayez crainte, ils sont simplement en train d’augmenter leur productivité collective. Le principal produit de l’activité de développement n’est pas le logiciel, mais le développeur lui-même. Cette paraphrase de Frédéric Le Play conclut ce résumé d’une thèse que j’ai eu plaisir à lire.

SOURCE

Le refactoring comme modèle du couplage homme-machine / Ophir Paz ; sous la direction de Jean-Baptiste Guignard. Thèse de doctorat : Automatique, Productique, Signal et Image, Ingénierie cognitique : Bordeaux : 2022.

Quelles prestations proposez-vous aux établissements de formation ?

Sat, 06 Jan 2024 00:00:00 +0000

En plus des cours, les établissements avec lesquels je travaille me sollicitent pour des prestations annexes, comme les jurys ou les suivis de mémoires professionnels. Je ne suis pas fermé à l'idée de travailler avec des établissements dans lesquels je n'enseigne pas, à condition que le sujet traité corresponde à mon coeur de métier. Les apprenants bénéficient de ma veille scientifique le temps de leur mémoire et au-delà.

Pratiquez-vous la cybersécurité ?

Fri, 05 Jan 2024 00:00:00 +0000

Pour du développement classique, comptez autour de 560€/jour. Pour avoir un tarif plus précis, demandez un devis.

Le tarif des prestations dépend de leur nature, de leur complexité, de l'endettement technique du projet, du lieu d'exécution ou de la durée de la prestation. Par conséquent, il nous est impossible de donner un chiffre. Cependant les devis sont gratuits, contactez-nous.

Pratiquez-vous la cybersécurité ?

Fri, 05 Jan 2024 00:00:00 +0000

La cybersécurité est bien trop vaste pour que quiconque puisse claironner qu'il en a fait le tour. Je suis développeur et mon rôle dans ce vaste écosystème est de livrer du code sécurisé. Je suis donc compétent en sécurité du code.

Les analyseurs statiques font partie de mon outillage (SAST) mais j'ai tendance à m'en méfier pour des raisons exposées dans ma veille. J'utilise les tests de vulnérabilité, ancêtres manuels des outils DAST, en attendant de me former à ces derniers.
J'ai tendance à privilégier une lecture du code et un typage sévère à l'usage d'outils de SCA, tant les versions actuellement sur le marché sont verbeuses et peu utiles à mon sens.

J'ai enfin des compétences en hygiène numérique, issues autant de mon parcours de geek que de ma formation en Intelligence Economique. Je peux faire de la sécurité des systèmes et réseaux à très petite échelle.

OxaControle

Mon, 01 Jan 2024 00:00:00 +0000

Laurent Frapier Entreprises - Décembre 2018 - Présent - Nouvelle Aquitaine

Reprise d’un projet de contrôle d’accès datant de 2013, réalisé avec Projects Partners en alternance. Maintenance des sites installés précédemment. Installation de nouveaux chantiers.
Changement d'échelle en 2020 (x10) nécessitant la mise en place d'une architecture logicielle plus solide. Refactoring et conversion à .NET6, puis .NET8 aujourd'hui.
Ajout de nouvelles features en TDD sur demande de certains clients. Ajout de tests a posteriori sur le code historique pour le renforcer.

Actuellement : En production sur sites allant du petit bureau au grand centre aquatique. Étude de nouveaux chantiers.

Les origines

L'histoire commence en 2013, j'étais en alternance chez Projects Partners, dirigée par Thierry et Rémi Balu. L'entreprise produit des logiciels à destination du BTP : Convertisseurs, applications mobiles et développements plus particuliers. Ce qui allait ensuite s'appeler OxaControle est né d'une demande de l'électricien Laurent Frapier. Il venait de remporter un marché d'électricité et de contrôle d'accès par badge. La première partie est son métier, pas la seconde. Le projet a donc été confié à Projects Partners.

L'équipe de Projects Partners était réduite, j'étais développeur en alternance et M. Balu dirigeait la société. Le projet était d'envergure : proposer une solution de contrôle d'accès complète et peu coûteuse, allant de l'interface de paramétrage à l'interrogation en RS485 des lecteurs.

La plateforme Raspberry Pi a été sélectionnée pour son faible coût et sa puissance suffisante pour diriger une poignée de lecteurs, autant de portes et une flotte de quelques badges. Le principal défi vint de la plateforme .NET, alors absente de Linux. .NET Core n'arrivera que quelques années plus tard. C'était alors Mono qui remplissait le rôle, avec un transpilage en Java très gourmand en ressources.
Le Raspberry est incapable de produire des signaux RS485 sans convertisseur adapté. Le tâtonnement a été long pour aboutir à une solution à base de convertisseurs TTL to RS485, branchés de manière exotique afin d'utiliser le bus en full-duplex. Ces deux éléments sont encore utilisés aujourd'hui sur le projet, garants de son faible coût.

Le projet a été déployé sur plusieurs petits sites. Il y fonctionne depuis plusieurs années sans nécessiter d'autres interventions que celles d'un électricien pour remplacer certaines pièces d'usure. Je n'ai été amené à intervenir qu'une seule fois sur ces sites depuis leur installation.

La reprise par l'Atelier

En 2019, Laurent Frapier me contacte afin de me proposer la reprise d'OxaControle et son développement. L'objectif est ambitieux : multiplier par 20 le nombre de portes, badges et lecteurs que l'application peut supporter. Deux défis se présentent à moi : la mise à l'échelle, dépassant de très loin les capacités des Raspberry Pi, et la reprise d'un code immature, réalisé quand j'étais encore étudiant.

Une année d'études et de remaniement du code ont été nécessaires afin de retrouver une qualité suffisante pour avancer sereinement. Refactoring, refonte de certaines parties, introduction de tests, changement de technologie, nouvelle architecture matérielle. Presque tout à évolué pour fiabiliser le projet. Covid aidant, notre premier bureau s'est transformé en laboratoire d'électronique improvisé.

Aujourd'hui

Une fois la solution au point vint le temps de l'installation sur site, terminée à l'heure où j'écris ces lignes. Le défi est achevé, désormais OxaControle peut s'adapter à toutes les tailles de bâtiment grâce à son architecture évolutive.
Le même code source peut être déployé dans plusieurs configuration : serveur central, contrôleur de bus, simple UI.
Le projet, désormais repris doit maintenant être consolidé et assaini, afin de s'attaquer à d'autres sites. Il reste trop d'étapes manuelles lors de l'installation et de la maintenance et le poids du code legacy, bien que fortement réduit par des tests adaptés, reste fort dans le projet.
De nouvelles fonctionnalités ont été développées sur demande d'un client. Tout le nouveau code est recueilli et développé par les tests (BDD&TDD)
Désormais installé sur un site d'envergure (80 lecteurs, 200+ badges), OxaControle devrait susciter l'intérêt d'autres maîtres d'oeuvre, nous serons là pour le faire vivre et évoluer, 10 ans après.

IFP

Mon, 01 Jan 2024 00:00:00 +0000

Institut de formation politique - Janvier 2020 - Présent - Paris

Reprise d’une application PHP/Laravel obsolète et délaissée depuis plusieurs années, de gestion de campagnes de dons pour des associations. Duplication du projet, assainissement du code et correction à chaud de bugs bloquants. Stratégies de contournement des problèmes les plus coûteux à résoudre. Sécurisation du Legacy derrière un VPN.

Le projet est actuellement en maintenance à long terme.

Un projet en deshérence

Le projet est un outil de gestion de dons, fait sur-mesure pour coller au workflow très spécifique du client. Basé sur Laravel 5, celui-ci a été livré en 2015, puis maintenu un certain temps par son créateur. Celui-ci n'a pas écrit de tests sur ce projet, pourtant d'une complexité conséquente. La suite de l'histoire est hélas classique : sans tests, impossible de s'assurer de l'absence de régressions. Sans cette sécurité, la moindre mise à jour, la moindre évolution et même le moindre débug deviennent des tâches fastidieuses à l'issue incertaine.

Le développeur d'origine quitte le projet quelque part à la fin de la décennie 2010. Sans tests et sans son concepteur, le projet devient un Code Legacy : personne n'ose le mettre à jour de peur de le casser. Les défauts qui se révèlent ne sont corrigés qu'à minima par un développeur bénévole. Arrive l'année 2020, où l'IFP fait appel à moi pour reprendre en main le projet. La priorité est la correction des bugs les plus urgents.

Une longue convalescence

Une fois les voies d'eau les plus urgentes colmatées, le projet est assaini et intégré à un pipeline d'Intégration Continue. D'abord réalisée en tant que bonne pratique, cette intégration s'avère rapidement utile afin de dupliquer le projet pour une autre association-soeur. Un rapport sur l'état du projet est produit, afin que le client réalise l'ampleur des travaux à effectuer pour remettre le projet sur les rails. Une stratégie de long-cours est choisie : l'existant restera en l'état, c'est-à-dire non testé et obsolète, mais les nouvelles fonctionnalités devront bénéficier des meilleures pratiques et d'un environnement technique récent.

Après 2 ans à maintenir le projet, un nouveau besoin apparaît. Celui-ci entraîne la création d'un nouveau projet Laravel, récent celui-ci. Le nouveau projet est réalisé selon les règles de l'art : test-first (TDD), intégration continue, one-button-deployment, etc. Une variante du Strangler Pattern utilisant Apache comme routeur est utilisée. Lorsqu'une URL existe sur le nouveau projet, celui-ci répond. Sinon la même URL est demandée à l'ancien code. Petit à petit, des fonctionnalités sont "volées" à l'ancien code et reproduites sur le nouveau.

La route est encore longue, mais la reprise du développement augure un bel avenir à un logiciel incapable d'évoluer avant sa reprise. D'autres fonctionnalités sont prévues. Elles nécessiteront le transfert d'autres morceaux de code vers le nouveau projet. Progressivement et par contagion, tout le code sera testé, donc testable, donc maintenable. Mon but est de pouvoir un jour tirer ma révérence.

Program and interface slicing for reverse engineering

Tue, 12 Dec 2023 00:00:00 +0000

🔨 Les développeurs sont condamnés à éternellement devoir pratiquer l’ingénierie inverse (reverse engineering). De mauvais systèmes seront toujours produits par le bois tordu de l’humanité. Même un bon code aujourd’hui pourrait paraître archaïque dans quelques décennies à peine.

🧠 Pratiquer l’ingénierie inverse requiert 2 compétences distinctes : savoir déchiffrer l’intention derrière un design d’une part et pouvoir comprendre le comportement d’algorithmes d’autre part. Nous savons depuis Weiser qu’une telle opération requiert la création de modèles mentaux sous forme de slices : des morceaux discontinus de logiciels obtenus en rassemblant dans notre tête l’ensemble des endroits que nous pensons reliés au problème étudié.

🎛️ Beck et Eichmann, deux chercheurs américains, proposent de dériver ce concept de slices afin de mieux coller à la réalité de l’ingénierie inverse. Au lieu de chercher les morceaux de code reliés à un souci, ils proposent aux développeurs de repérer les morceaux de code participant à une interface, c’est à dire ceux offrant une fonctionnalité au monde extérieur. Ils nomment cette technique interface slicing.

🤖 L’avantage ? Il est facile de s’aider d’outils capables de prendre une interface donnée et de mettre en évidence les slices y étant reliées. Ces travaux servent donc surtout aux développeurs d’outils.

SOURCE

J. Beck and D. Eichmann, “Program and interface slicing for reverse engineering,” Proceedings of 1993 15th International Conference on Software Engineering, Baltimore, MD, USA, 1993, pp. 509-518, doi:10.1109/ICSE.1993.346015.

Convergent contemporary software peer review practices

Mon, 04 Dec 2023 00:00:00 +0000

💡 La revue par les pairs a été maintes fois étudiée sous l’angle de la réduction des défauts. Qu’en est-il du partage du savoir ? Les auteurs ont étudié les pratiques de revue de code en vigueur dans l’Open Source, mais aussi chez Google, AMD et Microsoft. L’époque des process lourds est achevée, la majorité de la profession utilise désormais des méthodes de revue légères, moins formelles, voire laissant la part belle à la revue avant commit.

🤝 La revue de code d’est hybridée avec le Pair Programming, en devenant “une résolution de problèmes en groupe”, plutôt qu’une recherche méthodique de défauts. A ce titre, les auteurs notent que le nombre optimal de reviewers est de … deux. Cette vision de la review évite le context-switching que provoque le rejet simple de la modification.

🔦 Plus intéressant, les auteurs notent que les développeurs ne se limitent pas aux fichiers sur lesquels ils ont déjà travaillé lors d’une revue. Celle-ci leur permet donc de connaître plus de parties du projet que si aucune revue n’était en place. La connaissance est moins approfondie que si le développeur travaillait en pair programming, mais tout de même.

👁️‍🗨️ Ce papier est intéressant, car il montre à nouveau à quel point la revue de code est un compromis entre le pair programming et l’absence totale de double-validation. Rien n’interdit à une équipe d’être souple et de passer d’une pratique à l’autre selon ses besoin.

SOURCE

Peter C. Rigby and Christian Bird. 2013. Convergent contemporary software peer review practices. In Proceedings of the 2013 9th Joint Meeting on Foundations of Software Engineering (ESEC/FSE 2013). Association for Computing Machinery, New York, NY, USA, 202–212. DOI:10.1145/2491411.2491444

Domain-Driven Design in Software Development: A Systematic Literature Review on Implementation, Challenges, and Effectiveness

Fri, 10 Nov 2023 00:00:00 +0000

🔬 Enfin une revue de littérature sur l’efficacité de DDD ! Il n’y en avait jusqu’alors pas. Les conclusions des trois auteurs tendent à affirmer que DDD fonctionne mais avec de sérieuses réserves quant à la fiabilité de la littérature existante.

😶‍🌫️ Aucune manière standardisée de mesurer les performances de DDD n’a été adoptée par les différentes équipes, qui n’ont d’ailleurs pas étudié les mêmes questions. Le monde académique et l’industrie ne se sont pas rencontrés et ont mené deux types d’études disjoints.

🌶️ Les défauts de DDD ont en revanche été repérés par de nombreuses équipes : la méthode est exigeante, tant en compétences qu’en organisation. Globalement si vous n’avez pas une équipe de développeurs et d’experts métiers confirmés, habitués à travailler ensemble et une organisation agile mûre, commencez par cela.

SOURCE

Özkan, Ozan, Önder Babur and Mark van der Brand. “Domain-Driven Design in Software Development: A Systematic Literature Review on Implementation, Challenges, and Effectiveness.” ArXiv abs/2310.01905 (2023): DOI: 10.48550/arXiv.2310.01905

Lanza del Vasto : Pour éviter la fin du monde

Mon, 06 Nov 2023 00:00:00 +0000

Si vous louez un appartement pour vos vacances, vous cohabiterez probablement avec un de ces horribles petits bouddhas décoratifs. Ils signalent avec fort peu de discrétion le mauvais goût et le conformisme du décorateur, plus que sa réelle spiritualité bouddhiste. Peu de chances que vous ne trouviez une Vierge ou un crucifix, comme s’il s’agissait d’un tabou. Bouddha, yoga, mantra, dalaï lama et pourquoi pas chiatsu, zen et chi renvoient dans l’imaginaire occidental à une spiritualité exotique, donc vertueuse. Le crucifix, les calvaires, renvoient à la poussière des patenôtres et des pénitents, voire à l’Inquisition ou à la combustion récréative d’hérétiques.

Lanza del Vasto a parfaitement su incarner de cet appel à l’exotisme pour délivrer son message : enseignements pied-nus dans l’herbe, non-violence radicale, dialogue avec Gandhi et pensée profondément écologiste à une époque où celle-ci était marginale (les années 70). Coqueluche de nombre d’écologistes, figure du Larzac et du pacifisme, son enseignement n’est pourtant rien d’autre qu’un concentré de doctrine sur la liberté, la charité, le rôle du péché et même le Diable. Lanza a su adapter sa pastorale, dirions-nous aujourd’hui, sans rien renier des enseignements de Saint Thomas d’Aquin.

Ce petit livre surprenant est pour votre voisine cherchant à activer sa kundalini, pour votre oncle druide à mi-temps et pour toute personne oubliant un peu trop souvent que les « cathos » aussi ont une « spiritualité » au sens où l’entendent nos contemporains. Si ce livre leur plaît, vous pourrez leur faire découvrir le père Joseph-Marie Verlinde, longtemps curé du morceau de Cévennes où Lanza repose désormais.

Article initialement publié dans le journal paroissial du pays de Rouillac.

Encapsulation of legacy software: A technique for reusing legacy software components

Thu, 02 Nov 2023 00:00:00 +0000

🏚️ Parmi les composants obsolètes*, les plus difficiles à gérer sont ceux dont la technologie sous-jacente est dépréciée, voire abandonnée.

📦 Faut-il reprendre ou refaire de tels composants ? La question n’admet aucune réponse générale, trop de paramètres sont contextuels. Dans le cas où l’on choisit de reprendre, deux options s’offrent à nous : encapsuler ou adapter. Plus exactement, il s’agit d’un continuum, car l’encapsulation parfaite, celle qui ne requiert aucune adaptation, n’existe souvent pas.

🧑‍⚕️ L’encapsulation peut s’effectuer à plusieurs niveaux. Dans le plus grossier, le programme est lancé avec des entrées forgées, ses sorties sont converties dans le format du nouveau système. Dans le plus fin, le code du composant obsolète est modifié afin d’accepter les entrées telles que le requiert le nouveau sytème. Ce dernier est bien plus chronophage que le premier niveau.

⌛ La technologie était déjà mûre en 2000 quand ce papier a été écrit. Encapsuler est bien moins coûteux qu’un redéveloppement, mais au prix d’une fuite en avant. Maintenir le composant obsolète sous cloche sera de plus en plus difficile avec le temps. Ca n’est jamais une solution définitive, mais un moyen d’acheter du temps, afin de refaire le composant ou de modifier le besoin qui en est à l’origine.

* L’auteur utilise le terme de Legacy, impropre ici.

SOURCE

Sneed, H.M. Encapsulation of legacy software: A technique for reusing legacy software components. Annals of Software Engineering 9, 293–313 (2000). DOI:10.1023/A:1018989111417

Iterative reengineering of legacy functions

Fri, 27 Oct 2023 00:00:00 +0000

Ce que l’on connaît aujourd’hui sous le nom de Strangler Pattern en architecture trouve ses racines en 2001 dans un papier de 4 chercheurs italiens. Pour rappel, il s’agit d’encapsuler un composant Legacy afin de remplacer une à une ses fonctionnalités par leur équivalent dans une codebase propre. Les deux codebase cohabitent jusqu’à la fin du processus et la mort du Legacy se produit quand plus rien ne peut en être extrait.

Le papier décrit en détail le processus et donne un exemple. Le principe de tests d’équivalence, cousins des tests de non-régression est évoqué, afin de s’assurer que le nouveau système remplit le même service que l’ancien.

SOURCE

A. Bianchi, D. Caivano, V. Marengo and G. Visaggio, “Iterative reengineering of legacy functions,” Proceedings IEEE International Conference on Software Maintenance. ICSM 2001, Florence, Italy, 2001, pp. 632-641, doi:10.1109/ICSM.2001.972780

Cognitive biases in Software Development

Tue, 03 Oct 2023 00:00:00 +0000

🧠 Les biais cognitifs altèrent notre raisonnement et peuvent conduire à des comportements suboptimaux, voire socialement nocifs. La pandémie du Covid-19 fut un véritable étalage de biais de confirmation en bas et d’arguments d’autorité en haut, conduisant à une gestion hasardeuse de l’épidémie. Les développeurs n’échappent pas à ces biais dans leur activité. N’étant pas formés aux limites de leur cerveau, ils n’adaptent pas leur manière de travailler à ce fait.

🕵️ Une équipe de chercheurs a trouvé 28 biais en observant 10 développeurs dans leur travail quotidien, puis en interviewant 18 autres développeurs. Ils ont été rassemblés en 10 catégories. Pour chacune d’entre elles, les conséquences sur le code ont été analysées et des solutions ont été proposées.

🔧 Beaucoup de biais peuvent être évités par des améliorations de l’outillage, le biais de confort peut ainsi être corrigé par un outil suggérant une manière plus optimale d’effectuer une opération, comme le font les IDE de Jetbrains par exemple.

🤏 Le papier est court, suffisamment pour qu’un résumé plus exhaustif soit peu efficient.

SOURCE

Souti Chattopadhyay, Nicholas Nelson, Audrey Au, Natalia Morales, Christopher Sanchez, Rahul Pandita, and Anita Sarma. 2022. Cognitive biases in software development. Commun. ACM 65, 4 (April 2022), 115–122. DOI:10.1145/3517217

Captronic

Fri, 01 Sep 2023 00:00:00 +0000

Captronic - 4 sessions entre février 2023 et juin 2024 - Bordeaux

Formation TDD sur 3 jours auprès d'un public de développeurs, majoritairement dans l'embarqué. TDD est abordé sur des projets neufs ainsi que sur du Code Legacy.

La formation est partie du B-A-BA des tests pour cheminer jusqu'au plus complexe : introduire des tests sur un code qui n'en a jamais connu. Nous avons suivi un fil rouge afin d'apprendre le recueil du besoin piloté par les tests.

Les tests fonctionnels sont à l'honneur, mais nous abordons également les tests d'intégration, les tests unitaires ou encore les tests de vulnérabilité.

Beaucoup de clients ont des composants de bas-niveau pour ne pas dire du hardware. Nous évoquons les Fakes, véritables jumeaux numériques, utilisés pour garder la célérité des tests sur la machine du developpement, ainsi que les stratégies permettant de tester avec du vrai matériel en intégration continue.

WoW Dragonflight : réflexions sur l'héritage

Mon, 28 Aug 2023 00:00:00 +0000

Derrière des apparences cartoonesques et volontiers ludiques, les œuvres de fantasy cachent souvent une réflexion philosophico-politique. Dans sa 10ème extension, nommée Dragonflight, World of Warcraft rend omniprésente la question de l’héritage, en jeu dans le lore¹, mais aussi en dehors.

L’intrigue se déroule sur l’archipel natal des dragons de Warcraft, les Îles-aux-Dragons. Ces derniers ont caché leur foyer 10 millénaires auparavant, afin de le protéger lorsqu’ils partirent en guerre contre la Légion Ardente, un des principaux ennemis de la licence. Travaillés par un puissant appel, les dragons survivants convergent vers leur patrie retrouvée. Ils réalisent bien vite qu’ils n’arrivent pas sur une terre vierge : les habitants des lieux ont poursuivi leur vie sans eux. D’anciens ennemis laissés sur place s’opposent au retour des anciens seigneurs des lieux, les Aspects, nom donné aux chefs des cinq Vols Draconiques, des familles de dragons ayant chacune une couleur et des pouvoirs propres.

L’emphase est mise sur le Vol Noir, central dans les différents patchs, nom donné aux additions mineures de contenu qui ponctuent la vie d’une extension. Celui-ci n’a plus de chef à la suite de la corruption, la trahison et enfin la mort de son Aspect, Neltharion. Avant de se choisir un chef, l’ensemble de sa progéniture doit affronter un passé révoltant : expérimentations sur des créatures humanoïdes, esclavage, génocide, torture, alliance avec des forces obscures. Neltharion, véritable Shirō Ishii² de Warcraft, n’a reculé devant rien pour accroître son pouvoir, sous couvert de lutter contre les menaces pesant sur le monde.

Les réactions de la pléthorique progéniture de Neltharion couvrent tout l’arc des possibles : ses deux enfants les plus célèbres, Irion et Sabellian, s’affrontent à fleurets mouchetés afin d’hériter du titre prestigieux de leur père. Ils y renoncent de concert en constatant l’étendue des horreurs commises par leur géniteur, dont ils prennent peu à peu connaissance dans l’extension.

Ils découvrent notamment une armée d’hybrides, les Dracthyrs, créés en laboratoire par Neltharion, programmés pour le considérer comme un père. Alors que les Dracthyrs rejoignent les factions jouables, une partie entre en rébellion par intégrisme crispé, refusant d’amender quoi que ce soit de l’héritage qu’ils ont reçu, fut-il celui d’un tortionnaire, d’un traître et d’un esclavagiste. Cette rébellion, nommée la Flamme Fracturée, sert d’idiots utiles au quattuor d’antagonistes de l’extension : les Primalistes. Ce sont des dragons n’ayant pas accepté l’alliance passée par les Aspects avec les Titans, force cosmique représentant l’ordre, la magie et la technologie dans le monde de Warcraft. Les Primalistes veulent annihiler les créations des Titans et recréer le monde sur la base des éléments primordiaux (Terre, Air, Feu, Eau). L’utilisation d’intégristes butés par des primitivistes sournois est peut-être le message politique le moins subtil de l’extension.

L’existence des Dracthyrs amène la question de la filiation, connexe à celle de l’héritage : créés, non pas engendrés, sont-ils de même nature que leur « père », dont ils partagent partiellement le sang ?

La voie médiane, celle auquel le joueur est amené à s’identifier, est celle d’Ebyssian et du Dracthyr Ardenthal, l’un enfant biologique, l’autre une création de Neltharion. Ils assument l’héritage, mais en retirent les scories. Ils savent que la corruption qui a rongé leur père, mais aussi le leader des intégristes Dracthyrs, peut aussi les atteindre s’ils baissent la garde, sans développer de haine d’eux-mêmes. Cette voie médiane est clairement celle d’une tradition bien comprise et assumée. Cependant l’enfant d’adoption Ardenthal ne remplace pas l’enfant biologique Ebyssian à la tête du Vol Noir.

Outre le Vol Noir, au centre de l’intrigue, deux autres Vols n’ont plus de chef. Cela permet aux scénaristes d’aborder la question de la transmission du pouvoir : qui est digne de régner ? A quelles fins ? La réponse est invariablement la même : il faut un héritier pour assumer l’héritage. Cet héritier ne doit pas rechercher le pouvoir, mais être subsidiairement au service des autres. Il est d’abord au service de son Vol, mais doit se soucier des autres créatures des Îles sur lesquels les dragons exercent une suzeraineté de fait, noblesse oblige. Assurément la démocratie n’est pas un thème très vendeur dans les œuvres de fantasy. On préfère les souverains justes et unificateurs aux factions et autres partis, fréquemment du côté des diviseurs, donc des méchants. Depuis ses origines chez J. R. R. Tolkien, le genre n’a pas apostasié son message profondément chrétien, voire crypto-royaliste par endroits.

Concept-centric software development

Thu, 22 Jun 2023 00:00:00 +0000

💭 Quand un programme mue en véritable système, la cohérence des concepts devient un véritable tour de force. Les meilleurs n’échappent pas à ce problème et le journaliste tech Casey Newton se moquait de Google en tweetant : “Google Reminders est maintenant Google Tasks. Pour créer un Reminder, utilisez Calendar. Pour créer une Task, utilisez GMail. N’utiliser PAS Keep”. Ce phénomène est appelé par les auteurs “Entropie conceptuelle”.

🔮 Palantir a atténué ce problème en créant un dépôt centralisé de concepts, utilisé par les parties prenantes de ses différents logiciels. Ce projet répondait à la complexification croissante de l’ontologie interne, nécessitant un format commun pour standardiser des quantités invraisemblables de notes, mémos et autres documents de nature conceptuelle.

📚 Au sein de la complexité des logiciels, peu considèrent la complexité conceptuelle : quand des fonctionnalités sont créées, changées, remplacées, les concepts qui les accompagnent se décalent progressivement de leur définition d’origine. La solution est la même que pour le code : un refactoring régulier afin de réaligner les concepts avec leur définition. Seuls les outils varient : ils empruntent plus au knowledge management qu’au développement

SOURCE

Wilczynski, Peter A., Taylor Gregoire‐Wright and Daniel Jackson. “Concept-centric Software Development.” ArXiv abs/2304.14975 (2023) DOI:10.48550/arXiv.2304.14975

An approach for experimentally evaluating effectiveness and efficiency of coverage criteria for software testing

Thu, 15 Jun 2023 00:00:00 +0000

🧪 Un jeu de tests peut être efficace sans être efficient. L’efficacité désigne la capacité à détecter des défauts ou des régressions. L’efficience consiste à maximiser cette capacité de détection en fonction du nombre de tests. Cette distinction est important : les tests coûtent à écrire et personne ne veut voir 15 tests passer au rouge à la première évolution de son code.

🇮🇳 Deux chercheurs indiens ont voulu vérifier la corrélation entre critère de coverage (branch, statement …) et efficience du jeu de test minimal permettant de le satisfaire sur un code donné.

📶 L’intérêt de l’expérience est plutôt limitée pour le praticien, le coverage n’étant pas un indicateur fiable de la qualité d’une suite de tests. Les résultats en revanche sont intéressants : ils montrent une relation quasi-linéaire entre effort de test et efficicacité. Autrement dit nous ne connaissons pas de méthode de test miracle, offrant une efficience d’un ordre de grandeur supérieure aux autres. Nous sommes, dans l’état actuel des connaissances, condamnés à devoir tester plus pour sécuriser plus.

⚠️ Cette conclusion doit néanmoins être prise avec du recul : l’usage de mutants et la génération automatisée de tests confine ces conclusions au monde des tests unitaires. Il est impossible de déduire quoi que ce soit pour les tests de niveau supérieurs, souvent les plus utiles aux praticiens. Ce papier servira donc principalement à d’autres chercheurs, non aux développeurs.

SOURCE

Gupta, Atul & Jalote, Pankaj. (2008). An approach for experimentally evaluating effectiveness and efficiency of coverage criteria for software testing. STTT. 10. 145-160. DOI:10.1007/s10009-007-0059-5.

Security Risks in the Software Development Lifecycle: A Review

Tue, 13 Jun 2023 00:00:00 +0000

La sécurité des logiciels commence dès l’écriture du code. Un logiciel bien-né posera bien moins de défis à sécuriser qu’un infect bourbier. Trois chercheurs Kenyans nous proposent une revue de littérature exhaustive sur ce sujet autour de 3 questions : d’où viennent les vulnérabilités, quelles en sont les conséquences et comment les résoudre ?

Nous y apprenons que les vulnérabilités naissent du manque de connaissance ou de la nonchalance des développeurs, ainsi que de la faible priorisation de la sécurité par les product owners. Ces considérations sont jugées trop peu rémunératrices par des équipes sous-pression à court-terme. Autrement dit, les incitatifs à faire du code sécurisé sont encore trop faibles, alors même que l’on sait que les vulnérabilités sont plus coûteuses lorsque corrigées tardivement.

La partie sur les conséquences est la plus faible, la littérature disponible est trop maigre. Notre profession n’a pas l’habitude de publier ses rapports d’incidents. Il s’agit d’ailleurs d’un énorme problème pour la recherche. Rappelons-nous que l’aviation a progressé ainsi.

Enfin, les auteurs détaillent les nombreuses solutions disponibles, allant de la revue de code appuyée par un professionnel de la sécurité du code à l’analyse statique.

Ce papier est surtout une immense mine de sources et un bon point de départ pour qui s’intéresse au sujet.

SOURCE

Odera, David & Otieno, Martin & Ounza, Jairus. (2023). Security Risks in the Software Development Lifecycle: A Review. 8. 230–253. DOI:10.30574/wjaets.2023.8.2.0101.

Toward remaking Software Development to Secure it

Fri, 09 Jun 2023 00:00:00 +0000

L’ensemble des pratiques actuelles visant à sécuriser le développement de logiciels adoptent une approche accidentelle et réactive : les attaques sont analysées, catégorisées et les développeurs (éventuellement) formés. Cette pratique est défaillante : la sécurité a toujours un train de retard sur les attaquants.

Une piste prometteuse pour résoudre ces défis est le développement basé sur les propriétés, un paradigme émergent en développement. Ce paradigme permettrait par exemple d’empêcher des données sensibles de passer d’un composant sécurisé à un ne l’étant pas. L’auteur soutient que le flux de données est une propriété contrôlable dans un logiciel : un flux de données correctement encapsulé peut n’autoriser l’accès à son contenu qu’en échange d’identifiants valides.

L’idée est intéressante, je compte l’expérimenter de mon côté en attendant que des chercheurs testent ce qui n’est pour le moment qu’un avis d’expert.

SOURCE

Jenkins, Jonathan. “Toward Remaking Software Development to Secure It.” The Journal of the Southern Association for Information Systems (2022): n. pag. DOI: 10.17705/3jsis.00020

A Case Study on Design Patterns and Software Defects in Open Source Software

Tue, 06 Jun 2023 00:00:00 +0000

🏗️ Corrélation n’est pas causalité, mais l’usage de certains design patterns, comme Adapter, Command, Observer, State, Strategy, Template et Proxy réduisent de manière significative le nombre de défauts.

🧑‍💼 Ce résultat est obtenu par minage de projets open-source. Il n’est pas précisé si des résultats similaires ont été obtenus sur des projets commerciaux.

SOURCE

Onarcan, M. and Fu, Y. (2018) A Case Study on Design Patterns and Software Defects in Open Source Software. Journal of Software Engineering and Applications, 11, 249-273. DOI:10.4236/jsea.2018.115016

Software development: do good manners matter ?

Thu, 01 Jun 2023 00:00:00 +0000

🙊 Si un ticket n’avance pas assez vite, insultez les mamans des développeurs. Non seulement vous aurez passé vos nerfs, mais de surcroît il avancera encore moins vite, ce qui vous offrira l’occasion de redoubler d’injures.

🎩🤌 Un équipe italo-britannique confirme que la politesse des commentaires influe sur la priorisation des tickets, mais également sur l’attractivité de ceux-ci pour les développeurs. Plus le langage est fleuri, moins les mainteneurs se pressent pour résoudre un problème et plus ils tendent à attribuer une priorité basse au ticket.

🤰 L’étude portait sur des projets open-source, les auteurs ne précisent pas si leurs conclusions sont applicables en entreprise. Dans le doute, n’insultez pas les mamans des développeurs.

SOURCE

Destefanis G, Ortu M, Counsell S, Swift S, Marchesi M, Tonelli R. 2016. Software development: do good manners matter? PeerJ Computer Science 2:e73 DOI:10.7717/peerj-cs.73

Self-collaboration Code Generation via ChatGPT

Tue, 30 May 2023 00:00:00 +0000

🤖 ChatGPT est à la mode, selon ses partisans capables de changer l’humanité. Revenons sur terre avec un papier proposant de générer du code à l’aide de 3 instances ChatGPT 3.5, promptées pour occuper 3 rôles classiques, bien que dépassés, de la production de logiciels : analyste, codeur et testeur.

🔮 Les auteurs y font collaborer 3 instances du célèbre modèle de langage afin de générer du code, avec de meilleurs résultats que les modèles génératifs les plus récents, meilleurs même que ChatGPT 4 pris seul. Est-ce l’avenir du développement ? Pas vraiment si l’on analyse le papier.

🧮 Afin d’évaluer le modèle, les auteurs comparent ses résultats à des catalogues de problèmes algorithmiques. L’enoncé est donné au ChatGPT-analyste, qui collabore avec ses deux collègues. La solution est comparée au corrigé. Il s’agit donc d’épreuves d’algorithmique, non de développement de logiciels, qui dépasse largement ce seul travail.

📝 L’expérimentation a deux variantes : dans la première le modèle reçoit seulement une description du problème en langage naturel. Dans la seconde, la signature de la méthode attendue et les tests unitaires lui sont fournis. Hélas, il est difficile de savoir à quelle variante les résultats présentés dans le papier sont attribuables.

🧠 De l’aveu même des auteurs, ce modèle n’offre pas de résultats satisfaisants à des niveaux d’abstraction supérieurs à la fonction. Or il s’agit de la majorité de la plus-value d’un développeur. Cependant ce papier offre une piste sérieuse à une hypothèse personnelle : les outils capables de générer un code minimal passant un test du rouge au vert sont proches, accélérant le cycle TDD. Le développeur pourra alors se concentrer sur les étapes où son cerveau est le plus pertinent : le refactoring et l’écriture dudit test.

SOURCE

Dong, Yihong, Xue Jiang, Zhi Jin and Ge Li. “Self-collaboration Code Generation via ChatGPT.” ArXiv abs/2304.07590 (2023), DOI: 10.48550/arXiv.2304.07590

Computer system reliability and nuclear war

Thu, 25 May 2023 00:00:00 +0000

🚀 Le 3 juin 1980, un radar américain détecte deux missiles nucléaires lancés par des sous-marins. 18 secondes plus tard, ils sont indénombrables. Quelques secondes plus tard … plus rien. Vinrent ensuite des alertes montrant des missiles intercontinentaux, au Pentagone cette fois-ci. Les pilotes de B-52 ont ordre de décoller, jusqu’à un contre-ordre quelques minutes plus tard : fausse-alerte.

🐛 Dans l’espoir de reproduire le problème, le NORAD ne touche à rien. L’évènement se reproduit 3 jours plus tard et une puce est incriminée. Son défaut provoquait des confusions entre les scénarios de test, exécutés fréquemment, et de vraies attaques.

🌙 Ce bug n’est pas isolé, en 1960 le NORAD confondait une attaque soviétique et la lune. Sachant cela, est-il prudent de laisser le contrôle d’armes nucléaires à des machines ? Compte-tenu de la consommation d’alcool et de drogues rapportée par les services de santé des deux côtés du Rideau de Fer, l’humain ne ferait pas mieux.

⚛️ Comment piloter la dissuasion nucléaire, alors ? Notre technologie est aussi limitée que nous, notre honte prométhéenne est largement psychologique. Tout système est fondamentalement limité par notre capacité à écrire des spécifications complètes. Nous ne sommes pas des dieux omniscients.

💥 Alan Borning nous répond que la solution n’est pas technologique, mais politique. Les limitations technologiques sont indépassables, c’est au politique de s’assurer de ne jamais être en situation où une machine prend seule une décision, surtout si celle-ci est un tir nucléaire. L’accumulation de Close Call de la guerre froide prouve l’intérêt de la redondance machine-machine, machine-humain et surtout humain-humain, le plus le mieux. Hélas l’urgence réelle ou supposée des situations pousse à réduire les redondances.

SOURCE

Borning, Alan. “Computer system reliability and nuclear war.” Commun. ACM 30 (1987): 112-131. DOI:10.1145/12527.12528

When Only Random Testing Will Do

Tue, 23 May 2023 00:00:00 +0000

🎲 Les tests aléatoires sont mal vus. Au mieux un moyen de découvrir des bugs supplémentaires, au pire une stratégie de la dernière chance. Dick Hamlet tente de les réhabiliter et d’en faire la méthode de test de première intention pour deux classes de problèmes.

🎆 Lorsque le nombre de cas de test possibles pour un composant est trop élevé et qu’il n’est pas possible de repérer des valeurs limites pertinentes, on parle d’éparpillement des échantillons (sparse sampling). Il s’agit du premier cas dans lequel l’aléatoire s’en sort mieux que le déterminisme.

💾 Quant un programme manipule un état persistent, les développeurs tendent à abstraire celui-ci afin de contourner le problème. Ce faisant ils ne s’y attaquent pas vraiment. L’aléatoire peut résoudre ce problème. Il faut voir un test comme une série d’actions réalisées à partir d’un état persistent de départ. Ici, l’aléatoire concerne quelles actions seront réalisées dans quel ordre, non les valeurs injectées. Cette seconde partie est plus exigeante à lire.

🔀 L’auteur souligne que les méthodes présentées ne remplacent pas les tests déterministes, mais les complètement. Ainsi un même composant peut parfaitement être testé sous ces deux modes pour en tirer le meilleur.

SOURCE

Dick Hamlet. 2006. When only random testing will do. In Proceedings of the 1st international workshop on Random testing (RT ‘06). Association for Computing Machinery, New York, NY, USA, 1–9. DOI:10.1145/1145735.1145737

Explicit Namespaces

Tue, 16 May 2023 00:00:00 +0000

🗣️ La notion d’espace de nom est plus vaste que les “namespace” de C++ ou C#. Les packages de Java, les interfaces ou encore les scopes de Javascript sont des espaces de nom. Un espace de nom, pour étendre la définition, est un mécanisme permettant de retrouver un objet donné à partir d’un nom dans un contexte.

🪨 L’histoire commence avec des espaces de nom inflexibles. Deux globales ont le même nom ? Le programme plante. Vinrent ensuite les espaces de nom fixes, comme en java. Avec un préfixe unique à l’échelle d’Internet, chaque composant est libre d’utiliser les noms qu’il souhaite sans se soucier des autres. Les espaces de nom restreints suivent : c’est Python ou Javascript où chaque fichier possède son espace de nom. La globalisation nécessite un mot clé particulier. Enfin, l’état de l’art actuel utilise les conteneurs d’injection de dépendance afin de résoudre des dépendances nommées quand c’est nécessaire.

📦 Pour les auteurs, toutes ces méthodes doivent être dépassées par des langages incluant une gestion dynamique des espaces de nom : chaque composant s’exécute dans un contexte, incluant un espace de noms sur lequel l’appelant a un total contrôle. Le langage expérimental Piccola est de ceux-ci.

🧑‍🏫 L’inconvénient ? Les espaces de noms dynamiques sont extrêmement peu intuitifs pour nos cerveaux et un énorme effort pédagogique, absent de ce papier, est nécessaire. Un tel paradigme n’est prometteur qu’à mesure qu’il est utilisable par le commun des mortels.

SOURCE

Achermann, Franz and Oscar Nierstrasz. “Explicit Namespaces.” Joint Modular Languages Conference (2000). DOI:10.1007/10722581_8

Property-Based Software Engineering Measurement

Thu, 11 May 2023 00:00:00 +0000

📏 Notre métier est paradoxal, artisanal oserais-je dire. Le consensus sur les pratiques se fait naturellement, sans nécessiter de lourdes études pour trancher la plupart des débats. A contrario, celui sur les mesures est hérissé d’objections, de controverses et finalement n’a jamais vraiment émergé. Mesurer les logiciels est une gageure, encore en 2023.

🧮 En 1996, une percée majeure a été faite par trois chercheurs. Ils ont utilisé la théorie des ensembles afin d’obtenir des mesures fiables des logiciels, basées sur les composants et leurs interactions. Ils ont redéfini des mesures connues auparavant de manière formelle, comme le couplage, la complexité et la cohésion, mais ils ont aussi fait progresser le débat en séparant les mesures précédentes de “volume” des logiciels en deux mesures plus pertinentes : la taille (size) et la longueur (length) d’un logiciel.

🏫 Le papier nécessite quelques connaissances en logique et en algèbre pour être compris, mais rien d’insurmontable, un niveau légèrement supérieur au lycée suffit.

❓Le papier ne dit cependant pas à quoi peuvent bien servir ces mesures dans le quotidien des développeurs, mais ce problème est là depuis les origines de notre métier : nous n’avons jamais su quoi en faire.

SOURCE

Briand, Lionel Claude, Sandro Morasca and Victor R. Basili. “Property-Based Software Engineering Measurement.” IEEE Trans. Software Eng. 22 (1996): 68-86. DOI: 10.1109/32.481535

Programmers use slices when debugging

Tue, 09 May 2023 00:00:00 +0000

🐛 Lorsque nous débuggons, nous n’utilisons pas les mêmes représentations mentales que lorsque nous programmons. En réalisant un code, nous pensons les blocs que nous construisons. Lorsqu’il s’agit de le corriger, nous adoptons une autre représentation mentale que Mark Weiser nomme les Slices.

🔪 Une Slice s’obtient en retirant tout ce qui ne nous semble pas faire partie de la cause d’un bug dans un code. Ne restent à la fin qu’une poignée de variables et de méthodes éparses, que le développeur pense être de bons candidats pour l’origine du bug. Ces Slices sont rarement composés de morceaux de code contigus.

💡 Cette découverte n’apporte rien en elle-même, mais a ouvert la voie à de nombreux papiers en pédagogie du développement, en maintenance, en psychologie, etc.

SOURCE

Weiser, Mark D. “Programmers use slices when debugging.” Commun. ACM 25 (1982): 446-452. DOI:10.1145/358557.358577

Software Safety: Why, What, How

Thu, 04 May 2023 00:00:00 +0000

☠️ Un constat n’a pas pris une ride depuis 1986 : la sûreté des sytèmes s’effondre dès que l’on y introduit des logiciels. L’auteur, Nancy Leveson est avec Robert Glass un catalogue vivant des échecs de notre profession. Mars Polar Lander, le funeste Therac 25 ou le récent F-35 sont autant de rappels que la sûreté des logiciels est un véritable sujet.

☔ Ce papier est une introduction complète à une nouvelle matière : la sûreté des logiciels, une branche de la sûreté des sytèmes, qui se sont massivement informatisés dans les années 80. L’auteur balaye les problèmes essentiels et accidentels qui rendent le logiciel dangereux, en particulier s’il sert à piloter des machines aussi inoffensives que des missiles nucléaires ou des avions de combat.

🪱 La conclusion est presque technocritique : dans certains systèmes où le risque dépasse les innombrables bénéfices de l’informatique, peut-être vaut-il mieux s’abstenir d’introduire le ver logiciel dans le fruit de la sûreté.

SOURCE

Nancy G. Leveson. 1986. Software safety: why, what, and how. ACM Comput. Surv. 18, 2 (June 1986), 125–163. DOI:10.1145/7474.7528

Evaluating the effect of a delegated versus centralized control style on the maintainability of object-oriented software

Tue, 02 May 2023 00:00:00 +0000

💎 Un style de design jugé “plus élégant” qu’un autre par les plus expérimentés est-il forcément plus maintenable ? Non, car il est très fréquent que la maintenance soit exercée par des juniors qu’un style trop complexe. L’étude d’Arisholm et Sjøberg rappelle que la maintenabilité est relative à ceux qui maintiendront. Un logiciel n’est pas maintenable “dans l’absolu”, mais par rapport aux compétences de l’équipe de maintenance.

SOURCE

Arisholm, Erik and Dag I.K. Sjøberg. “Evaluating the effect of a delegated versus centralized control style on the maintainability of object-oriented software.” IEEE Transactions on Software Engineering 30 (2004): 521-534. DOI: 10.1109/TSE.2004.43

The prediction ability of experienced software maintainers

Thu, 20 Apr 2023 00:00:00 +0000

⏱️ Peut-on se fier aux développeurs pour estimer la durée d’une tâche de maintenance ? Non.

⭐ Peut-on se fier aux plus expérimentés pour faire légèrement mieux ? De manière presque imperceptible.

🎲 Ne demandez pas d’estimations aux développeurs. Roulez un dé, vous gagnerez du temps.

SOURCE

Jørgensen, Magne, Dag I.K. Sjøberg and Geir Kirkebøen. “The prediction ability of experienced software maintainers.” Proceedings of the Fourth European Conference on Software Maintenance and Reengineering (2000): 93-99. DOI:10.1109/CSMR.2000.827317

A comparison of methods for locating features in legacy software

Tue, 18 Apr 2023 00:00:00 +0000

🏚️ Lorsqu’il s’agit de savoir quels morceaux de code legacy sont reliés à une feature que l’on veut éditer, nous avons plusieurs outils à notre disposition, tous complémentaires.

🔍 Le plus simple est le bon vieux Ctrl+F/grep. Rapide, mais peu précis, il est très dépendant à la qualité du nommage, rarement exemplaire dans le code legacy. Les auteurs le recommandent en première intention, pour se familiariser avec le code.

🔦 Vient ensuite la reconnaisance logicielle, utilisant des tests afin de repérer quelles parties du code sont appelées par ceux-ci. Cette méthode est détaillée sur cette veille 10.1109/ICSM.1992.242542. Il s’agit de la méthode la plus fiable, mais aussi de la plus lourde à mettre en place. Elle est en outre incapable de repérer des concepts, contrairement aux deux autres.

🪢 Enfin, les graphes de dépendance peuvent parfois servir, mais il dépendent d’une bonne structuration du code en module, rarement présente dans les code legacy.

🧰 Ces trois outils se complètent dans la boîte à outils du développeur faisant face au code legacy.

SOURCE

Wilde, Norman, Michelle Buckellew, Henry Page, Václav Rajlich and LaTreva Pounds. “A comparison of methods for locating features in legacy software.” J. Syst. Softw. 65 (2003): 105-114. DOI:10.1016/S0164-1212(02)00052-3

Locating user functionality in old code

Thu, 13 Apr 2023 00:00:00 +0000

🏚️ Outre leurs nombreux bienfaits, les tests permettent aussi de localiser les fragments de code legacy impliqués dans une fonctionnalité donnée. Le principe est le même que les marqueurs en médecine nucléaire : mettez sous surveillance l’ensemble du code, en journalisant tous les appels à toutes les méthodes. Les outils modernes de code coverage permettent un suivi ligne à ligne. Une fois ce harnais posé, écrivez un jeu de tests utilisant la fonctionnalité à éditer.

💡 L’ensemble des méthodes appelées par votre test contiennent potentiellement des fragments de la fonctionnalité à éditer. Ce résultat reste à raffiner, mais la recherche montre un gain de temps potentiel par rapport à une recherche à la main.

SOURCE

Wilde, Norman, Juan Ángel Gómez, Thomas A. Gust and Don Strasburg. “Locating user functionality in old code.” Proceedings Conference on Software Maintenance 1992 (1992): 200-205. DOI: 10.1109/ICSM.1992.242542

What can commit metadata tell us about design degradation ?

Tue, 11 Apr 2023 00:00:00 +0000

📏 Les métriques fiables et utiles manquent aux développeurs et l’analyse statique du code piétine. Cependant un second filon est plus prometteur : le minage de commits. Il consiste en l’analyse des changements sur un VCS. Quatre chercheurs brésiliens ont réussi à quantifier la fragilité et la rigidité d’un code, deux mesures de Robert C. Martin, en mesurant les propriétés d’une série de commits.

💥 Si un commit édite de nombreux fichiers, il est dit dense, ce qui est une odeur indiquant une rigidité potentielle. La notion se rapproche de la shotgun surgery.

🪢 Si un commit touche à de nombreux fichiers éloignés dans l’arborescence, il est dit dispersé, ce qui est un odeur indiquant une fragilité potentielle.

💎 La méthode fonctionne, mais rencontre deux limites : la première est son inapplicabilité sans pré-traitement des commits. Merge commits, changements de style, documentation … ces changements polluent les mesures et les faussent, il faut donc un moyen de les exclure des calculs. La seconde est la nécessité pour les développeurs de respecter strictement le principe d’une feature par commit. Sans cela les facteurs de confusion rendent inopérante la méthode.

SOURCE

Oliva, Gustavo Ansaldi, Igor Steinmacher, Igor Scaliante Wiese and Marco Aurélio Gerosa. “What can commit metadata tell us about design degradation?” International Workshop on Principles of Software Evolution (2013).

Three steps to views: extending the object-oriented paradigm

Thu, 06 Apr 2023 00:00:00 +0000

💡 Le papier du jour décrit un mécanisme d’extension du paradigme objet n’ayant pas eu de suite, mais là encore, intéressant tant historiquement, car ses prémisses ont été implémentées, que comme point de vue novateur sur nos logiciels.

🧠 Pour les auteurs, la difficulté intellectuelle principale du code est notre capacité limité à nous représenter de gros objets ou un grand nombre de petits objets en interaction. Afin d’être manipulé, un tel système pourrait être synthétisé sous forme d’une vue, ne présentant que les éléments utiles au problème à résoudre.

👀 Le concept de vues est antérieur, il vient du monde des bases de données. Les auteurs proposent d’implémenter un mécanisme similaire dans les langages objet. Pour cela il faut 3 éléments successifs, qui manquaient à l’appel dans les langages objet de l’époque.

1️ Le premier élément est la capacité d’une classe à implémenter plusieurs interfaces. Ce point est évident pour nous en 2023, il ne l’était pas en 1989.

2️ Le second élément est la visibilité différenciée des variables d’un objet selon l’interface consommée. Là encore, rien de novateur pour nos yeux de 2023, C# le fait depuis les années 2000 avec les propriétés, que l’on peut définir en lecture seule dans une interface et en écriture dans une autre.

3️ Le dernier élément est la capacité pour les objets d’offrir une copie différente de leurs variables à chaque invocation d’une interface. A quoi cela sert ? A versionner, chaque instance de vue est une réprésentation du système à un moment, rafraîchir la vue revient à demander à celle-ci une nouvelle instance d’elle-même.

⏭️ Ce dernier élément n’est pas passé à la postérité, même si on peut le considérer comme un précurseur des techniques d’event sourcing.

🤝 Pour les auteurs, le principal bénéfice de ce système est la capacité pour une entité à éditer des composants logiciels ayant seulement des vues pour contrat. Ainsi libre à cette entité de refondre complètement l’implémentation sous-jacente sans se soucier des consommateurs tant que la vue ne change pas.

SOURCE

Shilling, John J. and Peter F. Sweeney. “Three steps to views: extending the object-oriented paradigm.” Conference on Object-Oriented Programming Systems, Languages, and Applications (1989). DOI:10.1145/74877.74914

Foundations for the study of software architecture

Tue, 04 Apr 2023 00:00:00 +0000

🏗️ Perry et Wolf n’ont pas à proprement parler inventé l’architecture. L’honneur revient à Schwanke qui, le premier, eut l’idée de connecter des composants pour créer ce niveau supérieur d’abstraction. Cependant, Perry et Wolf ont réellement fondé cette discipline aux côtés de Garlan en Shaw, déjà évoqués ici.

🏛️ Il ont pris pour modèle l’architecture en bâtiment, après avoir éliminé l’idée de prendre l’architecture hardware ou encore réseau, en raison de leurs différences inconciliables avec le logiciels. Peu naïfs, ils furent conscients des problématiques propres au logiciel et n’ont pas niaisement copié le savoir-faire de bâtisseurs de gratte-ciel.

🎨 Alors que le code est plus souple que le béton, chaque nouveau système est par essence sa propre architecture. Il est possible de trouver des traits communs, les styles architecturaux, mais les jeux de contraintes appliqués à chaque système sont trop dépendants du besoin pour être reproduits. Prudents, les auteurs ne s’avancent pas sur le caractère essentiel ou accidentel de cette propriété (contrairement aux partisans de l’ingénierie du logiciel).

🔗 L’architecture logicielle s’inspire mais ne copie pas. Pour Perry et Wolf, nous disposons de 3 éléments simples, les composants qui traitent la donnée, les connecteurs qui relient les composants et la donnée elle-même. Définir une architecture c’est donc créer un jeu de contraintes, définissant quelles catégories de composants peuvent être reliés à quelles autres et dans quelles conditions.

💡 S’arrêter là serait incomplet et ménerait à la dégénérescence ou à l’érosion de l’architecture ainsi conçue au fil des itérations. Il faut également expliciter le raisonnement derrière l’architecture et le diffuser, sinon les designers et développeurs vont à coup sûr rater la cible lors de l’implémentation. Pourtant, combien de maniaques du schéma format A1 font exactement cela en entreprise, se croyant supérieurs aux développeurs ?

SOURCE

Perry, Dewayne E. and Alexander L. Wolf. “Foundations for the study of software architecture.” ACM SIGSOFT Softw. Eng. Notes 17 (1992): 40-52. DOI:10.1145/141874.141884

Social Identity in Software Development

Thu, 30 Mar 2023 00:00:00 +0000

🏰 Au sein d’une entreprise, les développeurs tendent à mieux communiquer entre eux qu’avec les autres parties prenantes des projets. En résulte une très forte identité de groupe, créant des barrières entre les développeurs et les autres. Il n’est pas souhaitable de dissoudre ces groupes forts, qui sont gage de productivité sur des tâches complexes.

👽 Ces barrières sont bidirectionnelles, les non-développeurs jugent les développeurs arrogants, peu impliqués, voire improductifs. A l’inverse, les développeurs se voient comme des étrangers, des invités ponctuels parmi les non-développeurs.

🚀 Il est possible de réconcilier développeurs et non-développeurs grâce à un pattern organisationnel : les groupes de support éphémères. Des développeurs et des parties-prenantes se réunissent en “Task Force” afin de livrer une fonctionnalité ou de surmonter une difficulté. Ce groupe s’auto-dissout une fois son objectif accompli, afin que les développeurs ne le vivent pas comme une dilution de leur identité de groupe.

SOURCE

Bäckevik, Andreas, Erik Tholén and Lucas Gren. “Social Identity in Software Development.” 2019 IEEE/ACM 12th International Workshop on Cooperative and Human Aspects of Software Engineering (CHASE) (2019): 107-114. DOI:10.1109/CHASE.2019.00033

Comparing non-adequate test suites using coverage criteria

Tue, 28 Mar 2023 00:00:00 +0000

🧮 La recherche sur les tests est gourmande en puissance de calcul. Elle fait appel dans de nombreux cas au score de mutation d’un jeu de tests afin d’en estimer l’efficacité réelle. Or cette opération est coûteuse, même si d’un ordre de grandeur plus précise que le coverage.

📊 Le papier du jour restreint la question : si l’on doit classer des jeux de tests du plus efficace au moins efficace, le coverage est-il une méthode acceptable ? Il ne s’agit pas ici de quantifier ou d’estimer, mais de classer par ordre d’adéquation.

💵 La réponse est oui, le coverage, bien moins couteux que le score de mutation, offre un moyen rapide de classer des jeux de test, par exemple pour éliminer ceux qui ne sont pas pertinents dans une étude, avant d’effectuer des mesures plus compliquées uniquement sur ceux retenus.

SOURCE

Gligoric, M., Groce, A., Zhang, C., Sharma, R., Alipour, M. A., & Marinov, D. (2013). Comparing non-adequate test suites using coverage criteria. In 2013 International Symposium on Software Testing and Analysis, ISSTA 2013 - Proceedings (pp. 302-313). (2013 International Symposium on Software Testing and Analysis, ISSTA 2013 - Proceedings). DOI:10.1145/2483760.2483769

Attention span during lectures: 8 seconds, 10 minutes, or more ?

Thu, 23 Mar 2023 00:00:00 +0000

🧑‍🎓 Les étudiants sont attentifs au maximum 10 minutes, donc les cours magistraux appartiennent au passé ! Tout le monde a déjà entendu ce lieu commun, qui saute à pieds joints dans le biais d’appel à la nouveauté. Cours magistraux = pré-1968 = 💩. Sauf que les 10 min d’attention des étudiants sont un mythe. Débunk.

🎯 Le mythe ne vient pas de nulle part, des sommités de la pédagogie ont relayé ce chiffre. Pourtant aucune preuve ne l’appuie. Pire, depuis 1978 toutes les tentative d’en prouver la réalité ont tapé à côté ou échoué.

💤 On sait aujourd’hui que le temps d’attention dépend principalement de l’enseignant. Quelqu’un de barbant lassera avant 10 minutes, alors qu’avec professeur intéressant, l’heure peut être dépassée sans dommages.

🧨 La recherche a aussi montré que tout cours a ses temps forts, correspondant aux notions-clés. Si l’enseignant prend le temps d’insister sur l’importance d’une notion, il fait immédiatement remonter l’attention de ses étudiants pour les minutes suivantes.

⏱️ Enfin, sur la base de mesures physiologiques, il semble que la période la plus propice à la rétention des savoirs se situe entre 15 min et 30 min après le début du cours.

🚫 Les auteurs terminent en rappelant que le cours magistral fut un temps passé de mode, donc que le moindre chiffre pouvant justifier cette disgrâce fut utilisé. Pourtant l’état des connaissances est clair : il n’y a pas mieux pour une entrée en matière, même (et surtout) à l’heure d’Internet. Les autres méthodes restent pertinentes pour approfondir.

SOURCE

Bradbury NA. Attention span during lectures: 8 seconds, 10 minutes, or more? Adv Physiol Educ. 2016 Dec 1;40(4):509-513. doi: 10.1152/advan.00109.2016

A law-based approach to object-oriented programming

Tue, 21 Mar 2023 00:00:00 +0000

⚖️ Un paradigme n’ayant pas survécu peut nous être utile, car il offre un regard différent sur le code. L’approche par la Loi de Minsky et Rozenshtein n’a pas été implémentée dans un langage dominant, pourtant la lecture de ce papier change notre regard sur l’Orienté-Objet.

📮 Selon Alan Kay, l’idée derrière l’objet est la communication de messages entre des entités encapsulées, les objets. L’approche par la Loi va plus loin en décrétant qu’il n’est pas de la responsabilité des objets de savoir à qui ils émettent des messages. Comme dans le système postal, chacun dépose son message auprès d’un intermédiaire, qui seul décide qui le recevra. Cet intermédiaire applique des règles : la Loi.

🚌 Cette approche a indirectement inspiré les ServiceBus modernes, voire les microservices. La lecture de ce papier nous fait réaliser la véritable nature de nos objets au quotidien.

SOURCE

Minsky, Naftaly H. and David Rozenshtein. “A law-based approach to object-oriented programming.” Conference on Object-Oriented Programming Systems, Languages, and Applications (1987). DOI:10.1145/38765.38851

How do personality, team processes and task characteristics relate to job satisfaction and software quality ?

Thu, 16 Mar 2023 00:00:00 +0000

🤓 Si je vous dis “développeur”, avez-vous l’image d’un nerd introverti voire misanthrope en tête ? La recherche montre pourtant que les plus heureux au travail sont les plus agréables et consciencieux. Mieux : ceux produisant les logiciels les plus qualitatifs sont les extravertis.

💀 Vous pouvez cependant rester misanthropes, l’étude ne dit rien de cette option philosophique.

SOURCE

Acuña, Silvia Teresita, Marta Gómez and Natalia Juristo Juzgado. “How do personality, team processes and task characteristics relate to job satisfaction and software quality?” Inf. Softw. Technol. 51 (2009): 627-639.

On the Impact of Design Flaws on Software Defects

Tue, 14 Mar 2023 00:00:00 +0000

🦨 Les odeurs du code (ici nommées Design Flaws) sont corrélées positivement aux défauts des logiciels. Le plus fréquente des odeurs est la jalousie fonctionnelle (Feature Envy). Ces deux conclusions d’une équipe Suisse n’étonneront pas qui a l’habitude de lire des sources de projets legacy.

👀 La jalousie fonctionnelle désigne le fait, pour une classe, de faire plus appel aux attributs/getters d’autrui qu’à ses propres données. Elle augmente fortement le couplage et nuit à la lisibilité des classes. Elle est un signe d’une formation parcellaire ou insuffisante à l’orienté objet.

💪 Le remède ? Essayez de développer le jeu de la vie ou un bowling avec les règles Object Callisthenics, c’est radical.

SOURCE

M. D’Ambros, A. Bacchelli and M. Lanza, “On the Impact of Design Flaws on Software Defects,” 2010 10th International Conference on Quality Software, 2010, pp. 23-31, doi:10.1109/QSIC.2010.58.

The Humble Programmer

Thu, 09 Mar 2023 00:00:00 +0000

👴 Dijkstra est une personnalité du développement. Il est notre Confucius, largement cité, rarement lu. Un de ses plus célèbres papiers, The Humble Programmer raconte son histoire avec la programmation. Dans sa seconde partie, il disserte sur l’avenir de notre profession et sa condition de survie : atteindre la performance. Cela signifie que les développeurs ne doivent pas passer la majorité de leur temps à débugger, donc que les développeurs ne doivent plus mettre de bugs dans leurs programmes, tout simplement.

🐛 Comment atteint-on cette performance ? En créant des programmes intellectuellement maniables. Comment fait-on cela ? En remettant la célèbre citation de Dijkstra dans son contexte : “Tester peut être une manière efficace de trouver des bugs, mais jamais de prouver leur absence”.

🧪 Dijkstra parle ici des tests manuels après le développement. Il recommande plutôt de développer la preuve de validité et le programme main dans la main, car il s’agit de la seule manière de ne pas avoir de bugs. Un programme dont les tests sont l’ultime spécification n’a pas de bugs, seulement des tests manquants. Il suffit d’écrire ces tests pour ne jamais voir revenir ce “bug”.

♻️ Mieux, lorsque l’on a écrit une preuve de validité, il est possible d’itérer afin de trouver le programme valide le plus intellectuellement maniable. Le mot “refactoring” n’existe pas encore, mais le concept est posé. Alors, Dijkstra, un précurseur de TDD ?

SOURCE

Edsger W. Dijkstra, The Humble Programmer, ACM Turing Lecture 1972, EWD340

Direct and indirect connections between type of contract and software project outcome

Tue, 07 Mar 2023 00:00:00 +0000

💵 L’utilisation de prestataires au forfait est plus risquée pour le projet que si ceux-ci sont en régie. C’est la conclusion d’une étude norvégienne portant sur 35 projets du secteur public. Le forfait a bien plus de chances de devenir problématique pour toute une liste de raisons, bien entendu cumulables :

👉 La sélection des prestataires favorise les moins chers, donc les plus optimistes et les moins expérimentés. 👉 Le management s’implique moins, car un forfait est psychologiquement ou juridiquement conçu comme du fire and forget. 👉 Il est improbable qu’un forfait soit itératif et livre fréquemment 👉 Le management contrôle moins la compétence du prestataire au fil de la prestation. Elle refuse d’évaluer le risque d’incompétence avant la livraison.

👨‍💼 Si la régie pose aussi ses problème, elle est moins risquée pour le projet que le forfait.

SOURCE

Magne Jørgensen, Parastoo Mohagheghi, Stein Grimstad, Direct and indirect connections between type of contract and software project outcome, International Journal of Project Management, Volume 35, Issue 8, 2017, Pages 1573-1586, ISSN 0263-7863, DOI:10.1016/j.ijproman.2017.09.003.

Purposes, concepts, misfits, and a redesign of git

Thu, 02 Mar 2023 00:00:00 +0000

🙊 Git est un bon outil, mais le nombre d’appels à l’aide sur StackOverflow prouvent que son design est affreux. Deux chercheurs du MIT nous expliquent où le bât blesse à l’aide des techniques de design conceptuel.

🛑 Quiconque a pratiqué un peu connaît les défauts de git : difficile de changer de branche avec du travail en cours, de créer des variations locales sans les commiter, de comprendre l’état de tête détachée, etc. Pourquoi ? Car une régle fondamentale du design a été violée par git : la bijection concept/motif.

💭 Un concept est quelque chose que l’utilisateur doit comprendre pour utiliser un logiciel. Dans un bon design, chaque concept règle un problème, que l’on nomme son motif.

👉 Un concept sans motif est une complexité inutile.

👉 Un concept qui prétend régler plusieurs problèmes bâcle souvent les deux.

👉 Un problème qui n’est le motif d’aucun concept rend le logiciel incomplet.

👉 Un problème qui motive plusieurs concepts créé la confusion.

4️⃣ Git possède ces 4 catégories de défauts, analysés dans le papier. Il constitue une vraie leçon de design qui devrait être enseignée dans les écoles.

🌠 Les auteurs poursuivent en proposant à des utilisateur de tous niveaux de git l’essai de Gitless, un fork de Git respectant les canons du design conceptuel. Les résultats en matière de prise en main sont bien meilleurs.

SOURCE

Santiago Perez De Rosso and Daniel Jackson. 2016. Purposes, concepts, misfits, and a redesign of git. SIGPLAN Not. 51, 10 (October 2016), 292–310. DOI:10.1145/3022671.2984018

YNOV

Wed, 01 Mar 2023 00:00:00 +0000

YNOV - Printemps 2022 - Présent - Lyon, Nantes & Bordeaux

Modules de 30h à 80h destiné à des M1&M2 en développement.

Dev Logiciel avancé : comprend l'économie du logiciel, le recueil du besoin piloté par les tests, la qualité logiciel et le multitasking.
L'architecture et donc le design de logiciels, selon une approche rigoureuse et validée par la recherche académique.
Les tests, en particulier l'approche TDD&BDD, ainsi que le recueil du besoin piloté par les tests.

Comme à mon habitude, ce sont les étudiants qui ont choisi leur langage de travail, dans la limite de mes connaissances. J'ai eu à travailler selon les écoles avec du TypeScript, du PHP, du Java et du C#.

The coupling effect: fact or fiction

Tue, 28 Feb 2023 00:00:00 +0000

🧪 En théorie des tests, l’effet de couplage (Coupling Effect) désigne l’hypothèse selon laquelle un jeu de tests ne laissant pas passer des fautes simple ne laissera que marginalement passer des fautes complexes. Enoncée en 1978, il faut attendre 1989 et une étude d’Offutt pour l’appuyer à l’aide de preuves expérimentales.

👾 En utilisant le principe des tests de mutation, l’auteur valide l’hypothèse sus-mentionnée. Il va même plus loin en montrant que l’hypothèse du Programmeur Compétent n’est qu’une version extrême de l’effet de couplage.

🃏 L’hypothèse du Programmeur Compétent énonce qu’un développeur produira en général des logiciels “presque corrects”. Personne n’écrit le code d’un système d’exploitation par erreur en voulant développer un compilateur. Autrement dit, un développeur tend à écrire des mutants de rang faible (ayant peu de différences) par rapport au programme visé. Un bon jeu de test cherche à attraper ces erreurs, donc n’a aucun intérêt à attraper les mutants de rangs supérieurs. Cela reviendrait à vérifier que notre compilateur n’est pas, par erreur, devenu un système d’exploitation, soit une situation hautement improbable.

SOURCE

A. Offutt. 1989. The coupling effect: fact or fiction. In Proceedings of the ACM SIGSOFT ‘89 third symposium on Software testing, analysis, and verification (TAV3). Association for Computing Machinery, New York, NY, USA, 131–140. DOI:/10.1145/75308.75324

Experimental assessment of random testing for object-oriented software

Thu, 23 Feb 2023 00:00:00 +0000

🎲 Tester avec des valeurs aléatoire a-t-il un sens ? Sur un code implémentant un système de contrats (préconditions et postconditions), oui. Un étude suisse a obtenu d’excellents résultats en effectuant des opérations aléatoires avec des valeurs aléatoires sur un code programmé par contrats. Cette méthode de test trouve un nombre très important de bugs dès les premières minutes, moyennant suffisamment de puissance de calcul pour essayer un nombre significatif de combinaisons.

🧪 Ces résultats n’ont pas été reproduits sur d’autres types de code, ceux remplaçant les contrats par un typage fort impitoyable, par exemple.

SOURCE

Ciupa, Ilinca & Leitner, Andreas & Oriol, Manuel & Meyer, Bertrand. (2007). Experimental assessment of random testing for object-oriented software. 84-94. DOI:10.1145/1273463.1273476.

Is Design Dead ?

Tue, 21 Feb 2023 00:00:00 +0000

🤠 On reproche à eXtreme Programming d’être revenu à l’ancien temps du “Code&Fix” en rejetant la notion de planification du design. Martin Fowler rétorque qu’en effet, l’équipe qui ferait du cherry-picking dans les pratiques d’XP s’expose bien à un retour à l’ère des cowboy programmers. Dans un long plaidoyer, il explique que se libérer d’UML et de son cortège de diagrammes est absurde sans adhérer d’abord au coeur d’eXtreme Programming : 3 pratiques primant temporellement sur toutes les autres.

1️ Les Tests, sans lesquels tout le reste est impossible, car friable et invérifiable.

2️ L’Intégration Continue, qui permet de ne pas se marcher dessus à plusieurs. Elle nécessite les tests.

3️ Le Refactoring qui procède des tests et de l’intégration continue. Il est la clé permettant de diminuer suffisamment le coût du changement d’un système complexe afin qu’un design émerge en cours de route. Il permet de changer un aggrégat de solutions ad-hoc en design révélateur d’intentions, à comportement visible égal.

🆙 Ce n’est qu’une fois ces pratiques acquises qu’une équipe peut adhérer à d’autres pratiques d’eXtreme Programming.

SOURCE

Fowler, Martin. “Is design dead.” (2001).

35 years on: To what extent has software engineering design achieved its goals ?

Thu, 16 Feb 2023 00:00:00 +0000

🚀 En 1968 s’est tenue la conférence de l’OTAN sur l’ingénierie du logiciel. Une de ses tâches fut de définir le design de logiciels. Les participants ne sont pas partis d’une feuille blanche, mais ont d’abord rassemblé les définition du design dans les autres disciplines d’ingénierie. C’est d’ailleurs une des forces de ce papier : il est un des meilleurs résumés que je connaisse sur le design en général.

💣 Une fois les généralités passées, les participants ont essayé de sauver les meubles malgré les particularités du logiciel.

👉 Parce que le logiciel est en évolution permanente, son design et sa production sont indissociables. Le design de logiciels ne peut donc pas être fait totalement en amont. Hélas, 30 ans furent nécessaires pour en tirer les conclusions nécessaires et revenir au développement itératif et incrémental des années 60.

👉 Parce que le logiciel est intangible, il n’est pas posible de se bâtir une image mentale à partir des propriétés physico-chimiques ou géométriques du matériau travaillé. Il ne reste au designer que les besoins des utilisateurs pour se bâtir une intuition limitée de ce qui doit être fait.

👉 Parce qu’un logiciel est virtuel et que le développement est une discipline balbutiante, les métriques nécessaires à la mesure de sa qualité sont une terra incognita. Les designers perdent une source précieuse de feedback et doivent s’en remettre à l’intuition des développeurs (qualité transcendantale) ou à une satisfaction utilisateur qui arrive uniquement en fin de production.

🗿 Les participants à la conférence de Garmisch-Partenkirschen avaient toutes les cartes en main pour reconnaître l’ineptie de calquer le design de logiciels sur les autres disciplines d’ingénierie. Comme le souligne l’auteur, c’est l’orgueil voire l’idéologie qui interdit à l’époque de considérer les méthodes itératives, jugées “informelles et idiosyncratique” comme des méthodes d’ingénierie valable. Dans les années 60, la tradition n’était plus considérée comme une source de connaissance valable.

SOURCE

Simons, Christopher & Parmee, Ian & Coward, David. (2004). 35 years on: To what extent has software engineering design achieved its goals?. Software, IEE Proceedings -. 150. 337- 350. DOI:10.1049/ip-sen:20031198

On Understanding Types, Data Abstraction, and Polymorphism

Mon, 13 Feb 2023 00:00:00 +0000

🛡️ “Un type peut être vu comme une armure protégeant la représentation non-typée sous-jacente d’usages arbitraires ou illicites.”. Nous utilisons tous les jours des types, comme s’ils étaient naturels et intuitifs. Entiers, booléens, ou objets plus gros.

🦍 Nous avons appris à nous en servir par imitation, c’est à dire partiellement. Pour les maîtriser et en débloquer tout le potentiel, il est nécessaire de les approfondir.

📕 Luca Cardelli et Peter Wagner ont rédigé en 1985 un papier dense et exigeant, dont la lecture est néanmoins bénéfique à tout développeur voulant apprendre ce que renferment des notions comme les types, l’abstraction ou le polymorphisme.

🧮 Si vous ignorez ce qu’est le polymorphisme paramétrique ou ad-hoc, ou ce qu’est un treillis d’idéaux, sans pour autant aborder une thèse de mathématiques, ce papier est fait pour vous.

SOURCE

Luca Cardelli and Peter Wegner. 1985. On understanding types, data abstraction, and polymorphism. ACM Comput. Surv. 17, 4 (Dec. 1985), 471–523. DOI:10.1145/6041.6042

What Does 'Product Quality' Really Mean ?

Thu, 09 Feb 2023 00:00:00 +0000

💎 Que signifie la qualité ? Le mot a 5 définitions communes, complémentaires mais contradictoires. La difficulté dans tout projet et d’adopter une définition limitée, locale et équilibrée de celle-ci afin de chasser l’ambiguïté et les conflits. Le papier de David Garvin que je vous livre fait partie des plus importants de l’histoire de l’industrie, rien de moins.

🎨 Si vous êtes un romantique, un philosophe ou un artiste, votre vision de la qualité sera probablement transcendante. Cela signifie que la qualité sera pour vous indéfinissable, reconnaissable uniquement par l’expérience.

💹 Si vous êtes un économiste, la qualité sera orientée produit, c’est à dire vue comme la quantité d’un attribut désirable possédé par le produit.

💼 Si vous appartenez au côté commercial de la force, vous aurez une vision orientée utilisateur de la qualité. La qualité d’un produit est un plébiscite. Est qualitatif ce qui se vend, ce que préfère le consommateur.

👷 Chez les ingénieurs, l’approche orientée production est fréquente : un produit de qualité répond parfaitement aux spécifications du premier coup, point final.

💰 Enfin, pour un gestionnaire, la qualité est orientée valeur, c’est à dire qu’un produit de qualité fournit la performance et la conformité à un prix acceptable.

🧠 Qui a raison ? Le compromis raisonnable, qui ne sera jamais idéal pour aucune de ces catégories de personnes, et qui varie selon le produit à réaliser. Garvin recommande de définir la qualité précisément dans 8 dimensions pour chaque produit : performance, fonctionnalités, fiabilité, conformité, durabilité, maintenabilité, esthétique et qualité perçue, afin d’éviter les querelles entre les différents métiers à l’oeuvre.

SOURCE

Garvin, David A. “What Does ‘Product Quality’ Really Mean?” MIT Sloan Management Review 26, no. 1 (fall 1984).

Reversing Entropy in a Software Development Project : Technical Debt and AntiPatterns

Tue, 07 Feb 2023 00:00:00 +0000

💣 Plus un logiciel est complexe ou mal fichu, puis il a de prise au réel et plus il vieillit vite. C’est l’entropie du logiciel. Existe-t-il une crème anti-âge pour le code ? Non, hélas, mais des techniques permettent de ralentir, voire d’inverser ce phénomène.

♻️ Le refactoring permet de regénérer le code, mais il doit être ciblé pour être efficient. Refaire en permanence tout le design n’a aucun sens.

🏚️ La cible se nomme antipatterns. Ils sont des problèmes de design ou d’architecture connus et identifiables.

🦨 Comment ? En identifiant des odeurs que la plupart laissent dans le code.

🔧 Comment ? Partiellement grâce à des outils présentés dans la thèse, capable de repérer certaines odeurs, partiellement avec l’expérience et l’oeil de l’artisan.

⚠️ Toutes les odeurs ne ménent pas à des antipatterns et tous les antipatterns n’ont pas d’odeur, mais c’est mieux que rien.

SOURCE

Ramirez Lahti, Jacinto, Reversing Entropy in a Software Development Project : Technical Debt and AntiPatterns, 2020, University of Helsinki, Faculty of Science, Tietojenkäsittelytieteen osasto

A View of 20th and 21st Century Software Engineering

Thu, 02 Feb 2023 00:00:00 +0000

🧠 Si on analysait l’histoire du développement avec la méthode hégelienne ? Barry Boehm a essayé en 2006 et les leçons qu’il en tire sont intéressantes.

💽 Thése des années 1950 : l’ingénierie du logiciel est similaire à l’ingénierié hardware. L’humain est bien moins cher à l’heure que les ordinateurs, le développeur doit agir en ayant ce principe économique en tête : suroptimisation, vérification pointilleuse des programmes avant leur livraison. Le rapport nécessaire aux sciences, l’absurdité de la gestion de projet séquentielle et la rigueur sont les enseignements de cette période.

🪛 Antithèse des années 1960 : Code and fix (que Boehm appelle, improprement à mon avis “Crafting”). Les développeurs se sont rendus compte que le logiciel est infiniment plus facile à modifier que le matériel. De plus le coût des ordinateurs baisse drastiquement. L’idée d’un code en état de maintenance permanent fait son chemin, précurseure de l’agilité moderne. On commence à parler d’itérations par opposition aux méthodes linéaires.

🧱 Synthèse des années 70 et antithèse : formalisme. Face aux plats de spaghetti souvent hérités de la décennie précédente, mais également afin de ne pas revenir aux processus guindés des années 50, une vague méthodologique a déferlé dans la gestion de projet, donnant Waterfall et dans le design donnant la programmation structurée, le concept de couplage et les balbutiements de la qualité logicielle en général. Hélas, l’esprit Top-Down et réductionniste est venu gâcher la fête en considérant un logiciels comme un ensemble de silos.

♾️ Synthèse des années 80 : scalabilité. C’est l’époque des tests automatisés, de l’orienté objet, de l’architecture, des IDE … La productivité des développeurs s’accroît d’un facteur 10. C’est la fin des obstacles accidentels à la vélocité des développeurs. Hélas le mouvement est allé trop loin, croyant se passer des développeurs, menant au ratage du WYSIWYG ou au mirage du Model-Based Software Enginering.

♻️ Antithèse des années 90 : recyclage. Les développeurs sont incontournables, mais lents, alors pour accélérer la livraison, il faut réutiliser au maximum. Cela est permis par le développement de l’orienté objet et de l’architecture. Il faut faire générique, trop parfois, quitte à créer d’infects frameworks d’entreprise. C’est aussi l’époque de la défiance envers la planification, jugée comme retardant le time-to-market, seule manière de savoir si le produit colle au besoin. C’est aussi l’âge d’Internet et de l’Open Source.

📝 Je vous laisse découvrir la suite, ainsi que les prédictions de Boehm dans le papier lui-même !

SOURCE

Barry Boehm. 2006. A view of 20th and 21st century software engineering. In Proceedings of the 28th international conference on Software engineering (ICSE ‘06). Association for Computing Machinery, New York, NY, USA, 12–29. DOI:10.1145/1134285.1134288

Static analysis tools as early indicators of pre-release defect density

Tue, 31 Jan 2023 00:00:00 +0000

🐛 Les outils d’analyse statique de code sont un bon indicateur de la densité de fautes dans un code. Leurs résultats sont en effet fortement corrélés aux défauts trouvés lors de tests manuels. Si ces outils ne trouvent pas tous les bugs, ils ont de grandes chances de détecter les plus gros nids dans un ensemble de composants.

SOURCE

N. Nagappan and T. Ball, “Static analysis tools as early indicators of pre-release defect density,” Proceedings. 27th International Conference on Software Engineering, 2005. ICSE 2005., St. Louis, MO, USA, 2005, pp. 580-586, doi: 10.1109/ICSE.2005.1553604.

Toward understanding the rhetoric of small source code changes

Thu, 26 Jan 2023 00:00:00 +0000

🤫 Des chercheurs ont étudié statistiquement les changements d’une seule ligne de code, bref les “ça va, c’est une petite modification” que nous connaissons si bien. Accrochez-vous les chiffres sont contre-intuitifs.

♻️ 95% du code sera édité au moins une fois tout au long du projet. Aucun code ne doit être réalisé avec pour condition de ne jamais changer.

📝 95% des changements au cours d’un projet font moins de 50 lignes. Les petits changements sont plus fréquents que vous ne l’envisagez lors de la première release.

💣 Un changement d’une seule ligne n’a que 4% de chances d’introduire un défaut. C’est donc la répétition qui fait le poison en la matière. Le chiffre monte à 40% si le changement vient résoudre un bug existant. Le Defect Testing est donc bien votre ami.

✂️ Il n’y a aucune preuve qu’une suppression de moins de 10 lignes de code puisse engendrer un bug. La leçon la plus importante est donc de prendre les études statistiques avec des pincettes.

SOURCE

R. Purushothaman and D. E. Perry, “Toward understanding the rhetoric of small source code changes,” in IEEE Transactions on Software Engineering, vol. 31, no. 6, pp. 511-526, June 2005, doi:10.1109/TSE.2005.74.

Managing the development of large software systems

Tue, 24 Jan 2023 00:00:00 +0000

🤖 A l’origine de la méthode Waterfall et de ses descendants, dont le célèbre cycle en V, on trouve un homme : Winston Walker Royce. Peu après la conférence de Garmisch-Partenkirchen de 1968, il produisit une méthode révolutionnaire afin “d’utiliser au mieux les ressources en programmeurs”. Le vocabulaire annonce la couleur : le développeur doit se tayloriser.

🔃 Son idée repose sur l’ajout d’étapes précédant la boucle analyse/programmation, qui suffit aux petits projets. Il s’agit des phases de spécification, analyse, architecture et autres analyses plus ou moins détaillées. Rendons cependant justice à Royce, qui avait bien compris que les étapes de programmation et de tests allaient lever de nombreux problèmes, nécessitant de remonter de nombreuses étapes en arrière dans les phases de spécification. Son erreur a été de sous-estimer la fréquence de ces retours : il pensait que la majorité des problèmes seraient détectés dans l’étape suivant immédiatement celle qui les a causés.

💣 La seconde erreur de Royce est de croire en la linéarité de la relation entre la taille d’un problème et l’importance des changement qu’il occasionnera. Tout son argumentaire repose sur ce mythe : si un problème est petit, il n’occasionnera que de petits changements et la majorité du travail réalisé avant sa détection sera conservé. Il est donc rentable de tout spécifier par raffinements successifs jusqu’à rendre la tâche du programmeur triviale. Avec le recul, nous savons qu’un petit problème d’implémentation peut invalider des centaines d’heures de conception sur plusieurs étapes.

📚 La troisième erreur de Royce est de croire que la documentation remplace la collaboration. Il prône une médiation universelle des différents métiers à l’oeuvre sur un logiciel par le document papier. Il y voit deux avantages : trouver les responsables des erreurs et spécialiser les tâches. Si un acteur rédige une documentation en amont, il est possible de diviser le travail en aval grâce à une photocopieuse. Chacun a son exemplaire de documentation, son silo et ses tâches spécialisées à effectuer. Il illustre en évoquant les tests “réalisables par des acteurs moins coûteux que les programmeurs”. De plus, vu que chacun est forcé de décrire son avancement sur une documentation, il est facile de remonter à la source, donc de blâmer.

🧠 Il est difficile de jeter la pierre à Royce, car les études venues invalider ses préjugés n’étaient pas sorties. Il aurait cependant pu faire preuve de plus de prudence avant d’appliquer au développement de logiciels tous les lieux communs de son époque. Le leçon, pour nous, est justement là. Appliquons-nous benoîtement la dernière méthode dans l’air du temps, ou bien avons-nous des preuves empiriques ?

SOURCE

Royce, Winston. “Managing the development of large software systems: concepts and techniques.” International Conference on Software Engineering (1987).

Traits : Composable Units of Behaviour

Thu, 19 Jan 2023 00:00:00 +0000

🏹 L’héritage simple est trop limité. L’héritage multiple est trop dangereux. Les mixins sont maladroits. Si l’avenir était aux Traits ? Un trait est un ensemble de méthodes pures (au sens où elles ne mutent pas d’attributs) servant de blocs préfabriqués pour constituer des classes.

🧩 Un Trait peut spécifier des corps de méthodes, tant qu’elles n’accèdent pas aux données. Les Traits peuvent hériter et donc exiger la présence d’autres traits dans la classe. Un Trait n’a pas à être complet, il peut laisser certaines méthodes sans corps, afin que les classes les définissent.

📝 Plusieurs implémentations sont possibles, certains langages comme PHP adoptent un mot clé séparé, d’autres comme C# préfèrent simplement autoriser les méthodes dans les interfaces.

🧠 Le papier a en outre une définition originale et profonde de ce qu’est une classe, j’en recommande la lecture pour cette raison.

SOURCE

Schärli, Nathanael & Ducasse, Stéphane & Nierstrasz, Oscar & Black, Andrew. (2003). Traits: Composable Units of Behaviour. Proceedings ECOOP 2003. 2743. 248-274. DOI:10.1007/978-3-540-45070-2_12

What is object-oriented programming?

Tue, 17 Jan 2023 00:00:00 +0000

💡 L’orienté objet, c’est l’abstraction plus l’héritage. L’abstraction, c’est l’encapsulation, plus le typage. Voici la définition, adossée à un argumentaire historique, que donne Bjarne Stroustrup de la POO.

🌡️ Il regrette que “POO” ait été trop souvent un buzzword, collé aux langages “cool” du moment comme Ada. Au risque d’un parti-pris pour faire entrer son propre langage, C++, dans la catégorie orienté-objet, Stroustrup vient combler ce manque de définition.

📜 Le papier présente également un intérêt historique, car Stroustrup y retrace la filiation de la POO dans l’histoire des langages.

SOURCE

Stroustrup, Bjarne. “What is object-oriented programming?” IEEE Software 5 (1988): 10-20. DOI:10.1109/52.2020

On the notion of inheritance

Thu, 12 Jan 2023 00:00:00 +0000

🎨 L’héritage, comme toute chose, possède une essence et des accidents. Son essence est d’exprimer un lien conceptuel entre la classe et ses ancêtres. Ses accidents sont tous les usages plus ou moins défendables qui ont été inventés par les développeurs. Ainsi l’héritage peut servir à créer des modules, réutiliser du code, mêler les comportement de plusieurs classes, etc.

🤔 Est-ce légitime ? L’auteur ne donne son avis que dans de rares cas. Cependant, il conclut que l’héritage signifie de facto bien plus que le simple lien de spécialisation conceptuelle. Lire un code en partant du principe que tout héritage est à but conceptuel est un pari dangereux.

📜 Le papier ne s’arrête pas là : il est un traité sur l’héritage, un état de l’art détaillant les subtilités de ce concept. Sa lecture est une mine d’or pour le développeur qui souhaite approfondir l’orienté-objet.

SOURCE

Taivalsaari, Antero. “On the notion of inheritance.” ACM Comput. Surv. 28 (1996): 438-479.

Using Customer Acceptance Tests to Drive Agile Software Development

Tue, 10 Jan 2023 00:00:00 +0000

🧪 Connaissez-vous Customer Test Driven Development (CTDD) ? Probablement pas. Complètement éclipsée par Dan North et la célèbre méthode BDD, CTDD n’en reste pas moins la première méthode Story TDD (STDD) connue.

🔬 TDD, lorsqu’il est mal compris, mène à des aberrations, comme les projets testés 100% au niveau unitaire. Le terme d’origine est flou, alors Lisa Crispin remet l’église au centre du village : les tests doivent vérifier les comportements visibles, non les arcanes internes des programmes.

📖 Mieux : si les tests sont les spécifications du projet, le cahier des charges n’est qu’un doublon pataud à côté de tests automatisés de haut niveau, seule source de vérité évoluant avec le projet en permanence.

🗣️ Hélas Lisa Crispin n’est pas allée assez loin. Il manquait une révolution dans notre vocabulaire pour assoir les clients aux côtés des développeurs lors de la conception des logiciels. C’est chose faite avec l’article de Dan North publié un an plus tard : Behavior Driven Development.

📜 A cheval entre la note méthodologique et le billet de blog, j’ai longtemps hésité à passer le papier de Lisa Crispin sur cette veille scientifique. Sa valeur historique penche en sa faveur. Logiquement, ce résumé en appelle d’autres. En premier lieu, un résumé de l’article de Dan North sus-mentioné.

SOURCE

Crispin Lisa, Using Customer Acceptance Tests to Drive Agile Software Development, 2005, Methods And Tools

The most common causes and effects of technical debt: first results from a global family of industrial surveys

Fri, 06 Jan 2023 00:00:00 +0000

🏃‍♂️ Quelles sont les causes et les effets de la “dette technique”* sur les projets ? Les causes sont connues : les deadlines et les problèmes de planification en majorité. Les autres causes sont minoritaires ou illusoires.

⏱️ Les conséquences ? Une faible qualité du code, du temps passé à refaire, donc des retards de plus en plus importants menant à toujours plus de raccourcis douteux.

🇧🇷 Les chercheurs reproduisent indépendamment dans un pays différent les travaux de Yli-Huumo et al. déjà mentionnés ici (DOI:10.1007/978-3-319-19593-3_1)

* La dette technique est à l’origine un acte conscient de prise de raccourci en échange d’un remboursement au plus vite.

SOURCE

Rios, Nicolli & Spínola, Rodrigo & Mendonça, Manoel & Seaman, Carolyn. (2018). The most common causes and effects of technical debt: first results from a global family of industrial surveys. 1-10. DOI:10.1145/3239235.3268917

On the effectiveness of the test-first approach to programming

Tue, 03 Jan 2023 00:00:00 +0000

🧪 Les approches Test-First (TDD, TCR, …) découplent la qualité du logiciel de la compétence de l’équipe de développement. Contre-intuitivement, ces approches n’augmentent pas la qualité d’un logiciel, mais boostent la productivité de l’équipe.

🥇 D’excellents développeurs n’ont pas besoin de Test-First pour produire un excellent code. Un projet sans Test-First peut fonctionner, mais est enchaîné à des développeurs de haut niveau, ce qui peut être un problème au niveau RH. Adopter une méthode Test-First permet d’obtenir une qualité de code satisfaisante quelque soit le niveau de l’équipe.

💹 En augmentant la compréhension et la concentration des développeurs, Test-First augmente leur productivité quelque soit leur niveau. Cependant, elle augmente bien plus la productivité des développeurs les plus expérimentés que celle des novices.

♻️ Le papier n’évoque pas le principal intérêt de Test-First : la capacité à refactorer à l’envi, ce qui empêche la diminution trop rapide de la vélocité de l’équipe et donc augmente sa productivité à moyen et long-terme.

SOURCE

H. Erdogmus, M. Morisio and M. Torchiano, “On the effectiveness of the test-first approach to programming,” in IEEE Transactions on Software Engineering, vol. 31, no. 3, pp. 226-237, March 2005, doi: 10.1109/TSE.2005.37

Projects Partners

Sun, 01 Jan 2023 00:00:00 +0000

Projects Partners - Janvier 2023 - Mars 2023 - Marseille (Hybride)

Projects Partners n'est pas n'importe quel client. Il s'agit de l'entreprise où j'ai réalisé mon alternance pendant 2 ans à Bordeaux. Désormais basée à Marseille, l'entreprise existe toujours avec un important portefeuille de clients du BTP.

Nous nous sommes recontactés car ils ont besoin d'une autre paire de bras pour aider à la réalisation d'un démonstrateur sur Sharepoint, à partir d'une application .NET existante. Il s'agissait de prouver la capacité d'un projet standalone à devenir un SaaS dont la sécurité et les données seraient respectivement gérées par Sharepoint et Azure.

Actuellement : Prototype livre, en prospection afin de trouver des clients et de lancer le développement du produit.

An Experimental Comparison of Four Unit Test Criteria: Mutation, Edge-Pair, All-Uses and Prime Path Coverage

Thu, 22 Dec 2022 00:00:00 +0000

🎯 Adopter un critère quantitatif pour les tests n’est pas une bonne idée. Les différentes formes de Coverage ne garantissent en rien la qualité des tests censés couvrir le code. Aucune des méthodes de calcul de Coverage ne fait mieux qu’une autre.

👾 Le score de mutation, en revanche, est un indicateur plus sérieux. Il est capable de repérer beaucoup de bugs simples et d’erreurs d’inattention. Il échoue cependant face aux bugs plus vicieux.

SOURCE

N. Li, U. Praphamontripong and J. Offutt, “An Experimental Comparison of Four Unit Test Criteria: Mutation, Edge-Pair, All-Uses and Prime Path Coverage,” 2009 International Conference on Software Testing, Verification, and Validation Workshops, 2009, pp. 220-229, doi: 10.1109/ICSTW.2009.30.

Effectiveness of Test-Driven Development and Continuous Integration: A Case Study

Tue, 20 Dec 2022 00:00:00 +0000

🇳🇱 D’après une revue de littérature néerlandaise, TDD augmenterait modérément la qualité du code, mais aucune conclusion ne peut être tirée quant à la productivité des développeurs.

🙄 On peut regretter que cette revue de littérature ne vérifie pas si les études citées comparent TDD à Test-Last. Il est en effet malhonête de comparer TDD à l’absence de tests.

SOURCE

C. Amrit and Y. Meijberg, “Effectiveness of Test-Driven Development and Continuous Integration: A Case Study” in IT Professional, vol. 20, no. 1, pp. 27-35, January/February 2018, doi: 10.1109/MITP.2018.014121554

Is mutation an appropriate tool for testing experiments ?

Thu, 15 Dec 2022 00:00:00 +0000

🔬 Contrairement à l’aviation ou à la pharmacologie, nous ne publions pas nos échecs. C’est un grand manque lorsqu’il s’agit de valider des hypothèses de recherche. Aussi les chercheurs remplacent de vrais bugs par des faux lorsqu’ils étudient les moyens de les combattre. Deux outils sont principalement utilisés : la mutation et l’introduction manuelle.

👾 La mutation consiste à créer des mutants, des copies du code ayant subi un changement préprogrammé (inverser une condition, incrémenter une constante, supprimer une ligne, etc.)

🧑‍💻 L’introduction manuelle emploie un développeur expérimenté, payé pour introduire des bugs en amont de la recherche. Job de rêve s’il en est.

✔️ La mutation et l’introduction manuelle sont-ils des substituts légitimes aux vrais bugs ? Une équipe canadienne a vérifié. Les mutants obtiennent une bonne corrélation avec les vrais bugs, à condition que les opérateurs de mutation choisis soient correctement sélectionnés. L’introduction manuelle tend à introduire d’énormes biais. L’équipe recommande de toujours faire répliquer les études de basant sur cette seconde technique par d’autres chercheurs. Ce qui suppose de documenter le processus d’introduction des bugs.

SOURCE

J. H. Andrews, L. C. Briand, and Y. Labiche. 2005. Is mutation an appropriate tool for testing experiments? In Proceedings of the 27th international conference on Software engineering (ICSE ‘05). Association for Computing Machinery, New York, NY, USA, 402–411. DOI:10.1145/1062455.1062530

Representing concerns in source code

Tue, 13 Dec 2022 00:00:00 +0000

🔍 Pierre Boutang considérait la politique comme souci. Martin Robillard, lui, fait de même avec le code. Lorsque nous voulons l’éditer, il nous faut d’abord savoir quelles parties seront sous notre scalpel. Ce que nous recherchons alors, à coup de lecture de tests pour les plus chanceux ou de rétro-ingénierie pour les plus audacieux, ce sont des soucis (concerns en V.O).

❌ Chaque souci est un aspect du problème global résolu par le projet dans son ensemble. Hélas, il arrive fréquemment qu’un même souci soit adressé par plusieurs parties du code, on parle alors de “scattered concern”, un souci éparpillé. L’inverse survient quand un même code adresse plusieurs souci à la fois, on parle de “tangled concerns”, de soucis enchevêtrés.

✔️ Les canons du design conceptuel nous enseignent qu’un faut une bijection concept-problème pour faire un bon logiciel. Martin Robillard affirme qu’il faut également une bijection souci-module. Ces deux bijections sont des généralisations à des échelles différentes du plus grand principe de l’orienté-objet : Single Responsibility Principle (SRP).

SOURCE

Robillard, Martin & Murphy, Gail. (2007). Representing concerns in source code. ACM Trans. Softw. Eng. Methodol.. 16. 10.1145/1189748.1189751.

Aim, Fire

Wed, 07 Dec 2022 00:00:00 +0000

🤯 Je m’attaque à un monument : ni plus ni moins que l’article fondateur de TDD. Aim, Fire est un plaidoyer en faveur des approches Test-First. Kent Beck chasse un homme de paille fréquent : TDD n’est pas une méthode de test, mais une méthode de design, de réflexion et d’analyse.

🗿 Avec TDD, le développeur entre en dialogue avec le code. TDD ne dit pas quels tests effectuer, mais comment avancer sur un logiciel tel un sculpteur : en entrant en résonnance avec la matière que nous travaillons pour la tailler par petits incréments.

🗺️ A l’inverse, une méthode de test est là pour convertir des exigences en plan de test. TDD n’est pas une méthode de test, mais bien une pratique complémentaire à une méthode de test.

SOURCE

K. Beck, “Aim, fire” in IEEE Software, vol. 18, no. 5, pp. 87-89, Sept.-Oct. 2001, doi: 10.1109/52.951502

A Literature Review on Story Test Driven Development

Tue, 06 Dec 2022 00:00:00 +0000

🗊 Les méthodes de Story TDD comme BDD ont été analysées par plusieurs chercheurs. Deux canadiens en ont fait une revue de littérature. On y apprend que la méthode fonctionne, mais que les projets d’UI et les gros projets s’y adaptent très mal. L’outillage est encore très rudimentaire ou trop lourd.

💵 Cependant, la méthode parvient à créer des tests de non-régression qualitatifs et peu couteux, puisqu’ils sont réalisés en même temps que le recueil du besoin. Ce dernier est d’ailleurs facilité par le dialogue avec le code, qui permet de repérer les ambiguités et contradictions très tôt, contrairement aux spécifications papier.

🗓️ Les développeurs se sentent plus sûrs de leurs estimations, le projet est globalement plus à l’heure et respecte mieux les coûts. La communication entre parties prenantes est améliorée. Cependant l’adoption n’est pas aisée car elle implique tout le monde.

🔧 Le coût de maintenance de tels tests fait débat et peu de papiers l’ont étudié sérieusement.

SOURCE

Park, S., Maurer, F. (2010). A Literature Review on Story Test Driven Development. In: Sillitti, A., Martin, A., Wang, X., Whitworth, E. (eds) Agile Processes in Software Engineering and Extreme Programming. XP 2010. Lecture Notes in Business Information Processing, vol 48. Springer, Berlin, Heidelberg. DOI:10.1007/978-3-642-13054-0_20

Modularizing design patterns with aspects: a quantitative study

Thu, 01 Dec 2022 00:00:00 +0000

🆙 La programmation orientée aspect (AOP) est une tentative d’augmenter la POO comme cette dernière a augmenté l’abstraction de données. Peut-on remplacer avantageusement les design patterns du Gang of Four par des équivalents “aspectisés” ? Oui, mais l’avantage n’est pas net.

🙄 AOP obscurcit le code, il faut donc un bénéfice certain pour en justifier l’usage. Tous les design patterns aspectisés n’entrent pas dans ce critère. Peu gagnent en réutilisabilité par rapport à la version originale, seuls la moitié présentent une meilleure répartition des responsabilités et certains se retrouvent plus complexes voire plus couplés.

❔ Les quelques patterns pour lesquels AOP présente un bénéfice justifient-ils l’introduction d’un nouveau pradigme dans le code ?

SOURCE

Garcia, Alessandro F., Cláudio Sant’Anna, Eduardo Figueiredo, Uirá Kulesza, Carlos J. P. Lucena and Arndt von Staa. “Modularizing design patterns with aspects: a quantitative study.” LNCS Trans. Aspect Oriented Softw. Dev. 1 (2005): 36-74. DOI:10.1145/1052898.1052899

Exceptions and aspects: the devil is in the details

Mon, 28 Nov 2022 00:00:00 +0000

💣 La programmation orientée aspect (AOP) peut-elle simplifier la gestion des exceptions ? Oui mais uniquement dans les cas triviaux. Les cas complexes posent problème. C’est logique : AOP répond à la problématique des soucis transversaux (crosscutting concerns). Les exceptions n’en sont que rarement.

❔ Les rares cas où AOP serait utile pour gérer des exceptions justifient-ils un changement de paradigme connu pour assombrir le code ?

SOURCE

Filho, Fernando Castor, Nelio Alessandro Azevedo Cacho, Eduardo Figueiredo, Raquel Maranhão, Alessandro F. Garcia and Cecília M. F. Rubira. “Exceptions and aspects: the devil is in the details.” SIGSOFT ‘06/FSE-14 (2006). DOI:10.1145/1181775.1181794

On the Impact of Aspectual Decompositions on Design Stability: An Empirical Study

Thu, 24 Nov 2022 00:00:00 +0000

🪢 La programmation orientée aspect (AOP) promet de stabiliser le design lors de changements touchant les fonctions transversales d’un logiciel (crosscutting concerns). C’est même son acte de naissance, mais ces promesses sont-elles tenues ? Oui, mais au prix d’un couplage plus fort entre ces fonctions transversales et des modules n’ayant souvent rien à voir avec la modification effectuée.

⚠️ Le papier a une grosse limite : c’est une étude de cas sur un projet unique, dont la version orientée objet a été développée pour l’étude.

SOURCE

Greenwood, Phil & Bartolomei, Thiago & Figueiredo, Eduardo & Dosea, Marcos & Garcia, Alessandro & Cacho, Nélio & Sant’Anna, Claudio & Soares, Sergio & Borba, Paulo & Kulesza, Uirá & Rashid, Awais. (2007). On the Impact of Aspectual Decompositions on Design Stability: An Empirical Study. 176-200. DOI:10.1007/978-3-540-73589-2_9

Aspect-Oriented Programming

Tue, 22 Nov 2022 00:00:00 +0000

🔏 Les logs, le monitoring ou la sécurité ne sont pas de la responsabilité d’une seule partie du code. Ce sont des responsabilités de l’ensemble du code. Or, SRP et DRY, principes fondamentaux du design, nous interdisent de surcharger chaque classe pour prendre en compte tous ces soucis. Ils sont appelés crosscutting concerns ou soucis transversaux en français.

📦 A l’aube des années 2000, la complexité croissante des logiciels a descillé les yeux des développeurs sur ces problèmes. Plusieurs tentatives ont été faites. L’une d’entre-elles, Aspect-Oriented Programming, postule qu’il manque une couche d’abstraction entre les classes et les modules : les composants.

🪡 Ces composants, exprimés à l’aide d’une syntaxe propre, tissent (weaving) les classes et les agencent afin de répondre aux soucis transversaux sans violer SRP.

🌫️ AOP se voyait comme l’itération suivante de l’orienté-objet. Avec 20 ans de recul AOP a été très peu adopté, principalement à cause de l’obscurcissement du code qu’il provoque. Les développeurs sont difficilement capables de prédire le fonctionnement d’un programme à cause du tissage qui fait un usage massif de réflexion. Les IDE sont souvent aussi perdus, et incapables d’assister le refactoring d’un tel code.

💉 Cependant, on doit à AOP un vocabulaire (aspect, crosscutting-concern, etc.) et il a ouvert la voie à l’injection de dépendances moderne, qui offre un moyen plus lisible de gérer les mêmes problèmatiques.

SOURCE

Lopes, Cristina & Kiczales, Gregor & Lamping, John & Mendhekar, Anurag & Maeda, Chris & Loingtier, Jean-marc & Irwin, John. (1999). Aspect-Oriented Programming. ACM Computing Surveys. 28. DOI:10.1145/242224.242420

No Silver Bullet — Essence and Accidents of Software Engineering

Thu, 17 Nov 2022 00:00:00 +0000

🪄 Technologies miracles. Magiciels. No-Code. LinkedIn est farci de charlatans promettant de diviser par 10 le temps de développement, donc le coût de ces maroufles de développeurs. Pourtant Fred Brooks a clot le débat il y a 45 ans.

🏛️ S’inscrivant dans la tradition aristotélicienne, il distingue l’essence du développement et les accidents.

😶‍🌫️ L’essence de la profession de développeur consiste à concevoir les structures conceptuelles abstraites des logiciels. Osherove dit que nous bâtissons d’abord des châteaux de vent. Il s’agit de comprendre les besoins de nos clients et d’en assurer la cohérence. Cette partie est très proche du knowledge management.

🏚️ Les accidents sont tout le reste : contraintes matérielles, langages peu commodes, gestion de projet datée, IDE rudimentaires, etc. Avant les années 80, la gros de l’effort de développement était perdu par ces accidents. Pour Brooks, ce n’est plus le cas à son époque (1987). Je pourrais troller sur C ou Javascript, mais ce n’est pas le sujet.

⚠️ Le seul moyen de gagner en productivité d’un facteur 10 ou plus est donc de gagner du temps sur l’essence de notre profession. C’est bien moins simple que d’écarter un à un les obstacles accidentels comme nous l’avons fait depuis les années 50. Brooks affirme qu’il n’existe aucune technique ou méthode permettant cela à l’échelle de la profession. Il était modeste et affirmait “dans les 10 ans”. 45 ans après, le papier n’a pas pris une ride.

🐱‍💻 Restent quatre “hacks” pour contourner cette loi empirique : acheter un logiciel sur étagère, utiliser des techniques de prototypage, adopter une approche incrémentale et recruter un développeur d’exception. Rien de tout cela ne suffit, mais mis ensembles ces hacks permettent d’atteindre une grande vélocité.

🚩 Ce papier doit être lu par tout développeur, au cours de sa formation ou ensuite. Il fait partie de notre histoire et de nos lois.

SOURCE

Brooks, Jr, Frederick. (1987). No Silver Bullet Essence and Accidents of Software Engineering. IEEE Computer. 20. 10-19. DOI:10.1109/MC.1987.1663532.

Software Quality and Agile Methods

Tue, 15 Nov 2022 00:00:00 +0000

🔍 L’agilité offre d’excellentes garanties en matière d’assurance qualité, mais elle ne s’appuie pas assez sur les techniques de QA statiques. Ces dernières sont basées sur l’analyse du code et des documents projet par les parties-prenantes, sans exécution de tests automatisés ou manuels.

⚠️ Le risque est d’avoir un projet satisfaisant pour l’utilisateur, mais possédant une faible qualité de production, donc peu maintenable ou reprenable dans le temps, sans parler de sécurité ou de compatibilité à l’avenir.

🤝 Cependant, ces problèmes sont largement atténués par des pratiques connexes à l’agilité mais hélas absentes de certains frameworks omniprésents dans l’industrie : le pair programming et l’interaction directe et sans proxy entre les développeurs et les utilisateurs. Encore un point pour eXtreme Programming ?

❓ Le papier ne conclut cependant pas à la supériorité de waterfall ou de l’agilité en matière de QA, car leurs champs d’application ne se rencontrent pas vraiment.

SOURCE

Huo, Ming & Verner, June & Zhu, Liming & Ali Babar, Muhammad. (2004). Software Quality and Agile Methods. Computer Software and Applications Conference, Annual International. 1. 520-525. DOI:10.1109/CMPSAC.2004.1342889

A structured experiment of test-driven development

Wed, 09 Nov 2022 00:00:00 +0000

🍁 Une équipe canadienne a testé deux hypothèses : le code développé avec TDD est-il de meilleure qualité qu’un groupe cotrôle utilisant waterfall ? Le temps de développement est-il plus court avec TDD ?

➕ Les résultats tendent à montrer une hausse de la qualité, envisagée comme la conformité aux spécifications. La qualité interne du code, cependant, ne présente pas de différence significative avec une méthode plus traditionnelle.

➖ Le résultats montrent 16% de baisse de productivité des développeurs avec TDD. Cependant les chercheurs notent que la comparaison est injuste. Le groupe TDD n’a pas seulement livré du code, il a également livré des tests utilisables à l’avenir.

🍲 Ces résultats s’ajoutent à une grande marmite remplie de résultats contradictoires sur TDD.

SOURCE

George, Boby & Williams, Laurie. (2004). A structured experiment of test-driven development. Information and Software Technology. 46. 337-342. DOI:10.1016/j.infsof.2003.09.011

The Benefits and Consequences of Workarounds in Software Development Projects

Tue, 08 Nov 2022 00:00:00 +0000

🏃‍♂️ Quelles raisons poussent les développeurs à prendre des raccourcis, au détriment de la qualité du code ? Principalement le deadlines et la préexistence de raccourcis. Autrement dit, les raccourcis sont une drogue dure : une fois commencés, ils sont un habitude impossible à terrasser.

⏱️ Bien entendu, le papier et les 7 études de cas qu’il décrit est plus subtil, mais l’essence du problème est là : on ne peut pas demander une estimation précise à un developpeur, a fortiori un junior. Se baser sur une estimation est contraire à tout ce que nous savons des lois du logiciel et mènera à des raccourcis impossibles à juguler.

👌 Il n’y a que deux manières de faire un logiciel : donner une deadline mais rester souple quant au contenu de la livraison (agilité) ou donner un contenu, mais rester souple quant à la date de livraison. Toute autre conception est un mensonge plus ou moins grossier.

SOURCE

Yli-Huumo, Jesse & Maglyas, Andrey & Smolander, Kari. (2015). The Benefits and Consequences of Workarounds in Software Development Projects. DOI:10.1007/978-3-319-19593-3_1

On Transfer Learning in Code Smells Detection

Tue, 01 Nov 2022 00:00:00 +0000

🤖 Les techniques de Transfer Learning fonctionnent pour porter la connaissance de nombreuses odeurs du code d’un langage objet à un autre. Cela pourrait indiquer, comme le subodore l’artisanat du logiciel, l’universalité des odeurs du code.

🦨 Le papier est un preprint, mais si ses résultats sont confirmés, la recherche sur les odeurs du code sera grandement facilitée en permettant la mutualisation de celles-ci entre les communautés des différents langages.

SOURCE

Moabson Ramos and Rafael de Mello and Baldoino Fonseca, On Transfer Learning in Code Smells Detection, EasyChair Preprint no. 7717, EasyChair, 2022

Architecture Technical Debt: Understanding Causes and a Qualitative Model

Thu, 27 Oct 2022 00:00:00 +0000

📐 La déviation d’un projet par rapport à l’architecture prévue est une forme de dette technique. Sa gestion est différente de la dette “classique”.

🪲 Tel un insecte, un projet qui grandit doit muer pour adopter une architecture plus adaptée. Cette réarchitecturation ne peut pas être évitée, mais une bonne gestion de cette forme de dette permet d’en réduire la fréquence. Vu le coût d’un tel chantier c’est salutaire.

🔃 L’usage de méthodes agiles tend à augmenter l’accumulation de dette architecturale. Cependant ces méthodes permettent de mieux repérer le problème et de le traiter avant la crise.

😶‍🌫️ En tout cas, l’idée d’un projet immortel, éternel et immuable est à proscrire et le viellissement du logiciel doit être prévu budgétairement par le management.

SOURCE

Martini, Antonio & Bosch, Jan & Chaudron, Michel. (2014). Architecture Technical Debt: Understanding Causes and a Qualitative Model. Proceedings - 40th Euromicro Conference Series on Software Engineering and Advanced Applications, SEAA 2014. DOI:10.1109/SEAA.2014.65.

Interruptions in Agile Software Development Teams

Tue, 25 Oct 2022 00:00:00 +0000

🙉 Un développeur interrompu va mettre un certain temps à se remettre dans le jus, c’est le Context Switching, devant lequel nous ne sommes pas tous égaux. Optimiser la productivité d’une équipe requiert de minimiser les interruptions. L’agilité et sa mise en interaction permanente des développeurs avec les parties prenantes est bien moins optimale sur ce plan qu’un bon vieux tunnel.

✅ Le chercheur Manuel Wiesche donne plusieurs axes pour protéger les équipes agiles des interuptions.

♻️ En haut du podium, le respect scrupuleux des procédures : si le client veut changer un élément, il attend la fin de l’itération pour cela. Il n’interrompt pas intempestivement l’équipe en plein travail. Le temps d’attente est souvent trop long ? C’est un signe que les itérations doivent être plus courtes.

🦍 Ensuite, il préconise d’avoir une personne chargée de juger si le problème vaut le dérangement, une sorte de vigile de l’équipe. Ce peut être un Scrum Master, un PO ou un rôle tournant dans l’équipe. La canalisation des demandes au sein d’un outil de ticketing peut aussi servir ce but.

🤝 Enfin, l’usage de Pair Programming réduit les interruptions au sein même de l’équipe.

SOURCE

Wiesche, Manuel. “Interruptions in Agile Software Development Teams.” Project Management Journal 52 (2021): 210 - 222.

Software Development Waste

Thu, 20 Oct 2022 00:00:00 +0000

🔗 Une fois n’est pas coutume, le papier que je présente a déjà été vulgarisé par ses auteurs. Je vais me contenter de vous rediriger vers l’article qu’ils ont réalisé : Software Development Wastes.

SOURCE

T. Sedano, P. Ralph and C. Péraire, “Software Development Waste,” 2017 IEEE/ACM 39th International Conference on Software Engineering (ICSE), 2017, pp. 130-140, doi: 10.1109/ICSE.2017.20.

The Effects of Continuous Integration on Software Development: a Systematic Literature Review

Tue, 18 Oct 2022 00:00:00 +0000

⚠️ L’Intégration Continue n’a pas prouvé son efficicacité à ce jour, en partie parce que les études qui l’ont analysée jusqu’ici sont biaisées. C’est la conclusion détonnante d’une revue de littérature brésilienne.

🌁 Les chercheurs notent que 58% des papiers sur la CI ne la définissent pas avant de l’étudier, ou alors trop lâchement.

👎 Sur les 31 affirmations recensées, 6 sont parfaitement gratuites, c’est à dire sans preuves quantitatives ou qualitatives.

💥 Plusieurs affirmations, même appuyées par des chiffres, se contredisent.

🔴 Sur ce domaine comme sur d’autres, l’abondance de publications ne fait pas leur qualité et notre discipline manque encore gravement de rigueur.

SOURCE

Soares, Eliezio, Gustavo Sizílio, Jadson Santos, Daniel Alencar da Costa and Uirá Kulesza. “The effects of continuous integration on software development: a systematic literature review.” Empirical Software Engineering 27 (2022): 1-61.

The Video Store Revisited – Thoughts on Refactoring and Testing

Thu, 13 Oct 2022 00:00:00 +0000

🪙 La règle d’or du refactoring est l’interdiction d’éditer à la fois le code et à la fois les tests. Soit on refactore le code, et les tests garantissent de n’avoir rien cassé lors du processus. Soit on refactore les tests à code égal. Cette théorie est belle, mais irréaliste.

💣 Arie van Deursen et Leon Moonen nous expliquent que certains refactorings changent une interface de manière non rétrocompatible. Il est donc rigoureusement impossible de ne pas éditer le code ET les tests en les exécutant.

🧰 Ces refactorings, qu’ils appellent “Type E”, comptent hélas parmi les plus utiles de notre outillage : Extract Subclass, Inline Method, Replace Error Code with Exception et bien d’autres.

🌐 Comment s’en sortir ? Les auteurs ne le précisent pas. Pour ma part, je recommande de tester son code le moins unitairement et le plus fonctionnellement possible pour laisser le maximum de liberté de mouvement aux interfaces. Utiliser son IDE pour effectuer les refactorings réduit le risque d’erreur mais ne l’annule hélas pas.

SOURCE

Deursen, Arie van and Leon Moonen. “The Video Store Revisited – Thoughts on Refactoring and Testing.” (2002).

Agile methods : a comparative analysis

Tue, 11 Oct 2022 00:00:00 +0000

🔃 Qu’est-ce qu’une méthode agile, empiriquement ? En version courte, c’est une méthode développement objectiviste (visant l’adéquation entre besoin et solution), incrémentale et empirique (formée par les praticiens), fonctionnant avec des équipes à taille humaine afin de produire des logiciels fonctionnels en minimisant la documentation. La version complète se trouve dans le papier cité.

🔀 Chaque membre de la famille a ses spécificités et ses doctrines d’application. Il est possible de combiner certaines méthodes afin de compenser les faiblesses de l’une par l’autre.

💎 Dans Crystal/XP où XP sert de prototype de méthode, adapté à chaque projet.

🏉 Dans Scrum/XP, où XP vient apporter des pratiques de développement à Scrum qui n’est qu’une méthode de gestion de projet, un cadre dans lequel glisser une vraie méthode agile.

SOURCE

Strode, Diane E.. “Agile methods : a comparative analysis.” (2006).

The Role of Software In Spacecraft Accidents

Thu, 06 Oct 2022 00:00:00 +0000

🚀 Connaissez-vous le point commun entre le premier vol d’Ariane 5, Mars Climate Orbiter, Mars Polar Lander, Titan IV B-32 et SOHO ? Ce sont des missions spatiales ratées à cause de problèmes logiciels.

🤑 Dans tous ces cas, le risque associé aux défaillances logicielles a été minimisé ou nié afin de privilégier le respect des délais ou du budget.

💥 Cela a pris des formes multiples, mais récurrentes dans les accidents étudiés :

💣 Une diffusion de la responsabilité et de l’autorité. Les années 90 ont remplacé une culture de la supervision par une culture de l’incitation dans l’air du temps, sans pour autant s’assurer de son efficacité. De plus, en cas de dépassement de budget, le premier poste coupé était la sécurité, jugée redondante.

📧 La diffusion des informations était mauvaise. Les canaux étaient inadaptés à la gravité des informations. Sur SOHO, l’information sur le changement du logiciel des gyroscopes responsables de l’accident avait bien été transmise au pilotage … noyée dans des dizaines de mails.

🤠 Les spécifications étaient incomplètes, manquantes ou jamais mises à jour au cours du projet. Certaines parties du code étaient héritées de développeurs partis depuis longtemps, pratiquant le Cowbay Programming à haut niveau.

💋 KISS ? Connais pas. Le spatial c’est compliqué, alors quoi de mieux que des fonctionnalités compliquées et souvent inutiles ? Tous les projets accidentés avaient un code source encombré par de telles choses, souvent “au cas où”.

⛏️ Des morceaux de code ont simplement été minés dans les dépôts des anciennes missions et réutilisés sans tests, sur du matériel différent. Après tout, ça a fonctionné ! On retrouve ici le même schéma qu’avecle Therac-25, étudié par la même Nancy Leveson.

🤨 Les mauvaises pratiques furent légion, comme la non-séparation de systèmes critiques ou l’affichage de messages d’erreur distincts des informations normales. A ce stade, qui est étonné ?

🧪 Last but not least, le code ne comportait souvent aucun test automatisé. Nous sommes dans les années 90, pour rappel. Les campagnes de relecture du code et de tests manuels étaient effectuées sans trop de moyens ou de sérieux, pour économiser le budget.

🤦 Le rapport entier mérite la lecture, tant les similitudes entre les accidents spatiaux et le quotidien du développeur lambda sont édifiantes. Certaines anecdotes prêteraient à rire si elles n’avaient pas crashé des millions de $ d’argent public.

SOURCE

Leveson, Nancy G.. “Role of Software in Spacecraft Accidents.” Journal of Spacecraft and Rockets 41 (2004): 564-575.

The Effect of Lexicon Bad Smells on Concept Location in Source Code

Tue, 04 Oct 2022 00:00:00 +0000

😒 Il est plus difficile de s’orienter dans un code au nommage obscur. En effet, les odeurs lexicales augmentent le temps qu’un développeur met à retrouver les occurrences d’un concept dans un code.

🥼 La conclusion peut paraître évidente, mais comme souvent, mieux vaut une source académique pour convaincre les plus récalcitrants.

🦨 Les odeurs lexicales sont une type d’odeur du code lié à un mauvais nommage. On y trouve la contraction extrême, les termes vagues ou flous, la confusion nom/verbe, l’absence de relation d’hyponymie dans les héritages, etc.

👀 Peu d’outils sont aujourd’hui capables d’épauler les développeurs dans l’élimination de ces odeurs, le pair programming ou la relecture par autrui restent les seuls moyens de s’en prémunir.

SOURCE

S. Abebe, S. Haiduc, P. Tonella and A. Marcus, “The Effect of Lexicon Bad Smells on Concept Location in Source Code,” in 2011 11th IEEE Working Conference on Source Code Analysis and Manipulation, Williamsburg, VI, 2011 pp. 125-134. doi: 10.1109/SCAM.2011.18

Refactoring Test Code

Wed, 28 Sep 2022 00:00:00 +0000

🛸 Quiconque a déjà pratiqué les tests et le refactoring en même temps s’est rendu compte que le code de test ne se refactore pas de la même manière que le code testé. 4 chercheurs néerlandais ont en effet identifié des odeurs et des refactorings qui lui sont propres.

🤗 Dites bonjour à Mystery Guest, Test Run War, Assertion Roulette du côté des odeurs et à Setup External Resource, Reduce Data, Introduce Equality Method du côté des Refactorings.

SOURCE

Deursen, Arie van, Leon Moonen, Armand van den Bergh and G. Kok. “Refactoring test code.” Report - Software engineering (2001): 1-6.

Software Engineering - As It Is

Mon, 26 Sep 2022 00:00:00 +0000

🤦‍♂️ En 1979, Barry Boehm listait 10 lois d’un projet logiciel réussi. Il notait qu’aucune de ces leçons n’avait vraiment été retenue par les développeurs de l’époque. Rien d’original. Sauf que Boehm est un troll : il avait déjà publié le même papier en … 1961. Rien n’a changé en 18 ans.

🪦 Le sel c’est qu’en août 2022, Boehm nous a quittés sans que grand chose n’ait changé. Eventuellement, certaines lois sont devenues caduques, sans que la profession n’applique mieux les connaissances actuelles que celles d’hier.

SOURCE

Barry W. Boehm. 1979. Software engineering-as it is. In Proceedings of the 4th international conference on Software engineering (ICSE ‘79). IEEE Press, 11–21.

An empirical investigation into the role of API-level refactorings during software evolution

Thu, 22 Sep 2022 00:00:00 +0000

🐛 Vous voulez réduire le nombre de bugs d’une API ? Laissez vos développeurs faire ce $£%!§#@ de refactoring qu’ils demandent depuis des semaines. Mieux, laissez-les décider seuls du moment de refactorer. Cela n’a presque que des avantages :

👉 Le temps moyen de résolution d’un bug chute entre 35% et 63% après un refactoring.

👉 Le nombre de bugs résolus augmente entre 25% et 30% après un refactoring.

⚠️ Le papier présente un facteur de confusion : il est possible que le nombre de bugs résolus soit lié à de mauvais refactorings qu’il faut ensuite corriger. Cependant le temps moyen de résolution est une donnée fiable.

SOURCE

Kim, Miryung, Dongxiang Cai and Sunghun Kim. “An empirical investigation into the role of API-level refactorings during software evolution.” 2011 33rd International Conference on Software Engineering (ICSE) (2011): 151-160. DOI:10.1145/1985793.1985815

Energy-Driven Software Engineering

Mon, 19 Sep 2022 00:00:00 +0000

🔋 Quels langages sont les plus économes en énergie ? C’est une question pertinente quand on connaît la consommation énergétique, donc en partie le bilan carbone de l’IT. Mieux développer est une chose, mais passer sur un langage plus économe est plus facile, au moins pour les nouveaux projets.

🥉 Sans surprise, les langages interprétés comme Python, PHP et Ruby sont en bas du classement.

🥈Au-dessus on retrouve Javascript, C# et C++ dans certaines configurations.

🥇 Sur le podium, C++, Java et C.

⏬ L’étude n’a pas ciblé les dernières versions en date, ce qui peut fausser les résultats pour vos langages préférés, mais l’ordre de grandeur est bien valable.

SOURCE

Oprescu A., Koedjik L., van Oostveen S., Kok S., Energy-Driven Software Engineering

Towards a theory of Conceptual Design for Software

Wed, 14 Sep 2022 00:00:00 +0000

💭 Nous sommes taillés pour appréhender et utiliser des concepts depuis notre enfance. Quoi de plus naturel que d’en retrouver aussi dans les logiciels. Ils aident le développeur à se retrouver dans son code, mais surtout, ils permettent à l’utilisateur de comprendre le potentiel du logiciel qu’il utilise.

💡 Tweets et Hashtags sur Twitter, Corbeille et Fenêtres sous Windows, Instance et Equipement sur World of Warcraft. Un logiciel qui réussit expose des concepts clairs.

📚 Un excellent logiciel n’a même pas besoin d’un manuel pour vous les amener. Ce que l’on nomme Game Design dans les jeux vidéos existe tout aussi bien dans les autres formes de logiciels, et même dans la vie courante : s’il vous faut un manuel pour prendre l’ascenseur, son concepteur a échoué.

💣 A l’inverse, il est possible de définir la complexité d’un design comme suit : un système où les actions de l’utilisateur ont des effets directs qu’il ne peut pas voir et des effets indirects qu’il ne pourra pas anticiper.

1️⃣ Pour atteindre la simplicité, il faut que chaque concept soit lié à un et un seul problème appelé son motif. Chaque motif doit quant à lui être adressé par un et un seul concept pour ne pas créer la confusion.

🔗 Un exemple de cette logique est expliqué dans un autre papier co-écrit par le même auteur : Purposes, concepts, misfits, and a redesign of git.

SOURCE

Jackson, Daniel. “Towards a theory of conceptual design for software.” 2015 ACM International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Software (Onward!) (2015): n. pag. DOI: 10.1145/2814228.2814248

F-35 Joint Strike Fighter : Problems Completing Software Testing May Hinder Delivery of Expected Warfighting Capacities

Mon, 12 Sep 2022 00:00:00 +0000

✈️ Le fameux avion F-35 américain est vendu à de nombreux pays avant même son achèvement, malgré des retards et des capacités très en-deça de ses spécifications. Un facteur de retard n’est autre que, surprise, la suite logicielle embarquée.

⏲️ En 2014, le GAO, équivalent américain de notre Cour des Comptes, rapportait des retards chroniques dans les livraisons des logiciels de contrôle mission.

💣 En cause ? Des bugs, un décalage chronique entre le cahier des charges et la version livrée, ainsi que la cohabitation de multiples versions du logiciel rendant pénible le développement.

🤦 13 mois de retard, qui ont provoqué une réaction du Congrès : mettre plus de moyens sur le développement. La Loi de Brooks n’est toujours pas assimilée.

SOURCE

F-35 Joint Strike Fighter: Problems Completing Software Testing May Hinder Delivery of Expected Warfighting Capabilities GAO-14-322

Effect of team diversity on software project performance

Fri, 09 Sep 2022 00:00:00 +0000

🙃 Rarement définie, encore moins adossée à des études solides, mais pourtant présente dans les discours managériaux, la diversité est le mot à la mode. Ce n’est pas faute de papiers sur le sujet. Qu’en dit la recherche ?

3️⃣ D’abord qu’il faut distinguer 3 types de diversité :

La diversité de connaissances (Knowledge Diversity) qui varie avec la formation, le poste, etc.
La diversité sociale (Social Diversity) qui représente la diversité des couches sociales et des genres.
La diversité des valeurs (Value Diversity) qui représente la diversité des communautés, des cultures et des civilisations.

💣Ensuite, que toutes les diversités ne se valent pas. La diversité produit toujours des conflits qui peuvent être de 2 types : interpersonnels ou liés à la tâche. Les seconds sont productifs, les premiers destructifs.

🤼 Enfin, que chaque type de diversité est corrélé à certains types de conflits, donc à une variation de la productivité :

🟢 La diversité des connaissances (KD) semble augmenter dans tous les cas la performance d’une équipe : différents points de vue produisent des solutions complémentaires, par le mécanisme des conflits liés à la tâche. De plus, les spécialisations différentes évitent bien des conflits interpersonnels dus à l’égo.

🟡 La diversité sociale (SD) n’a pas d’effet clair sur les performances. Elle peut augmenter ou diminuer les deux formes de conflit, selon les cas.

🔴 La diversité des valeurs (VD) augmente principalement les conflits interpersonnels, diminuant la productivité.

🪄 Les chercheurs recommandent au manager avisé de diversifier socialement et professionnellement ses équipes, tout en prenant garde à choisir des profils compatibles entre eux par leurs valeurs et leur vision du monde. Est-ce ce que l’air du temps désigne par diversité ? J’en doute.

SOURCE

Liang, Ting-Peng & Liu, Chih-Chung & Lin, Tse-Min & Lin, Binshan. (2007). Effect of team diversity on software project performance. Industrial Management and Data Systems. 107. 636-653. 10.1108/02635570710750408.

Combating architectural degeneration: a survey

Tue, 06 Sep 2022 00:00:00 +0000

💢 Lorsqu’un logiciel vieillit, il prend en complexité, ce qui a pour conséquence de baisser la vélocité des développeurs : le code est de plus en plus difficile à changer. Une des explications à ce phénomène est la dégénérescence architecturale.

📐 Lorsqu’un logiciel est créé, il possède une architecture, consciemment définie ou émergente. Cette architecture possède une part variable de règles explicites et d’intentions implicites : les lois et l’esprit des lois.

💫 Avec le temps, les développeurs oublient l’esprit des lois, c’est la dérive architecturale (architectural drift) et font des entorses de plus en plus fréquentes aux lois, c’est l’érosion (architectural erosion). Ce dernier phénomène est à rapprocher de l’hypothèse de la vitre brisée.

❓ Comment réaligner l’architecture et le code ? Les chercheurs donnent deux pistes :

👁️‍🗨️ Extraire régulièrement l’architecture à l’aveugle par reverse engineering, pour la comparer au schéma d’architecture d’origine.

♻️ Effectuer du refactoring pour corriger le tir, ce qui implique la présence de tests automatisés à haut niveau.

SOURCE

Lorin Hochstein, Mikael Lindvall, Combating architectural degeneration: a survey, Information and Software Technology, Volume 47, Issue 10, 2005, Pages 643-656, ISSN 0950-5849, DOI:10.1016/j.infsof.2004.11.005.

A Brief History of Software Development And Manufacturing

Thu, 01 Sep 2022 00:00:00 +0000

⚙️ Selon Ashish et Akshay Kakar, l’histoire des approches de développement logiciel est la même que celle des autres industries, en accéléré.

🪛 A ses balbutiements, dans les années 50, l’approche Code&Fix est un décalque de la production artisanale d’avant 1910.

🏭 Ensuite, dans les années 70 le développement est passé par une phase de taylorisme proche de ce que l’industrie faisait dans les années 1910.

🏎️ Vint la phase Lean des années 90, calquée sur celle que l’industrie connut 20 ans auparavant.

🗒️ Enfin, l’Agile Manufacturing des années 90 aurait été portée chez les développeurs dans les années 2000.

🔮 Ce modèle simplifié, donc imparfait, de notre histoire sert le but que ses auteurs lui ont fixé : prédire l’avenir de notre profession en regardant ce qu’il se fait dans l’industrie.

🤓 Sauf si la prochaine révolution industrielle venait d’abord du développement pour ensuite essaimer ailleurs. Ce n’est pas un scénario improbable.

SOURCE

Kakar, Ashish & Kakar, Akshay. (2020). A Brief History of Software Development and Manufacturing.

Chiffrer en Artisan : Le forfait agile

Mon, 29 Aug 2022 00:00:00 +0000

Travailler en indépendant sans céder aux sirènes du pseudo-salariat des contrats en régie est compliqué. La principale barrière est financière. Les logiciels sont des produits complexes, qu’il est impossible de chiffrer avec exactitude. En régie, le risque de bugs ou de dépassement du temps est assumé par le client. Le développeur est payé comme un journalier, avec obligation de moyens, non de résultat. Certains clients ne veulent pas assumer ce risque. Certains développeurs ne veulent pas être ainsi déresponsabilisés. Je vais détailler ma méthode de chiffrage permettant d’intégrer le risque des logiciels dans le prix, afin d’être rentable en forfait.

⚠️ Cet article est une démarche pédagogique, non une démarche de transparence. La méthode de calcul présentée est authentique. Cependant, je ne souhaite pas dévoiler mon TJM ou les taux que je pratique pour compenser le risque. Si vous voulez un prix, demandez-moi un devis. Si vous ne vous intéressez qu’à la méthode de calcul, sans justification théorique, allez directement à la partie 2 : Compenser les risques.

Les risques du métier

Les développeurs sont nuls en estimation. Ce n’est pas un accident, mais bien l’essence même de notre profession qui l’explique.

Les estimations logicielles ont une capacité prédictive inversement proportionnelle à la complexité du logiciel réalisé. Vous avez bien lu : du logiciel. La fonctionnalité à implémenter n’est pas le seul facteur de complexité, il faut également compter dans la complexité l’ensemble de l’existant. Autrement dit, plus votre logiciel a du vécu, plus il est compliqué d’estimer le temps que prendra l’ajout d’une fonctionnalité nouvelle, a fortiori complexe.

A cela il faut ajouter le vieillissement du logiciel, décrit par Parnas, Lehman et Henderson. Pendant qu’il est développé, votre logiciel se dégrade de trois manières :

Parce que, n’étant pas un demi-dieu, vous développez de manière imparfaite.
Parce que le monde bouge autour de votre logiciel. Plus le développement dure, plus il faut inclure à celui-ci des phases de mise à jour des dépendances ou d’adaptations diverses à un monde qui bouge. Tout cela prend du temps.
Parce que le besoin à l’origine de la spécification que vous implémentez change certes imperceptiblement chaque jour, mais cela représente un décalage énorme au bout de quelques mois.

Les facteurs humains ne sont pas non plus à négliger comme le rappelle Fred Brooks : votre travail n’est pas réductible à une somme de jours/homme, encore moins en équipe. Certaines heures seront plus productives que d’autres, par exemple. Plus vous serez nombreux dans l’équipe, plus la variabilité de la productivité sera grande.

Pour ces raisons (et bien d’autres), il est impossible d’estimer précisément le temps d’implémentation d’une fonctionnalité non-triviale sur un logiciel non-trivial. C’est une loi empirique du logiciel. Toute action basée sur une estimation représente une prise de risque.

Qui est responsable ?

S’il est impossible d’avoir des prédictions fiables sur le coût d’un développement, contractualiser est une gageure. Quelqu’un doit accepter le risque et payer éventuellement les dépassements. Pour un salarié, c’est facile : il n’a qu’une obligation de moyens, l’employeur paie son salaire. Un freelance en régie est dans la même position : il est payé à la journée, pas à la tâche. Seules d’éventuelles pressions psychologiques peuvent venir perturber l’équation, mais ça n’est pas le sujet de cet article.

La régie n’est pas toujours souhaitable cependant. Certains clients font appel à un indépendant afin d’externaliser un développement dont ils ne souhaitent pas s’occuper. Ils veulent du clé-en-main.

L’inverse de la régie est le forfait. Le développeur donne un prix et une envergure. Il assume l’intégralité du risque de dépassement à ses frais et prend une marge en échange. Ce risque, nous l’avons vu n’est pas négligeable pour des projets simples et courts. Il est suffisamment important pour que le développement de projets complexes ou longs soit assimilable à un processus chaotique. Un forfait simple ne peut pas convenir pour autre chose que les petits projets triviaux sur lesquels il s’applique déjà (sites vitrine, moulinettes de données, etc.). Le risque, donc la marge prise, seraient trop importants, ne justifiant pas le service rendu par le logiciel.

La seule possibilité pour les projets complexes est le développement itératif et incrémental (IID). C’est une autre loi empirique du développement, appliquée avec succès par des équipes salariées et vérifiée par la recherche académique. Il réduit l’incertitude de l’estimation en la bornant volontairement à une plage de temps courte.

Il n’y a que deux manières de faire des logiciels

Un projet possède 4 variables et ne peut pas en bloquer plus de 3. Un projet logiciel en bloque 2 par sa nature même.

Que l’on soit en régie ou au forfait, il ne faut pas perdre de vue qu’il n’existe que deux manières de produire des logiciels fiables : donner un délai fixe, mais accepter une livraison incomplète ou donner une liste ferme de fonctionnalités, mais accepter un délai incertain.

Nous savons depuis plusieurs décennies que la qualité logicielle est un primat, sauf dans de rares cas (prototypes ou dette technique bien comprise). Ne pas viser l’excellence n’a aucun sens tant la vélocité à moyen et long terme des développeurs est abaissée.

Nous savons également qu’il est inutile d’ajouter des moyens à un projet démarré : c’est la Loi de Brooks. Le développement est une œuvre intellectuelle. Modifier l’équipe en charge d’un logiciel va ralentir à court et moyen terme la production de manière brutale.

Il ne reste que deux variables libres dans les projets logiciels. Bloquez-en une, vous savez laquelle restera pour encaisser l’incertitude du projet.

Compenser les risques

Depuis la Babylone antique, les hommes ont adopté un outil simple pour compenser les risques financiers dans le temps : les taux d’intérêt. Je ne compte pas réinventer la roue, car le concept est connu de tous.

Le forfait simple

Pour calculer des intérêts, il faut une somme, une durée et un taux périodique.

Pour obtenir la somme, il faut réaliser une estimation. Il s’agit d’une durée en jours ouvrés, correspondant au temps que vous pensez dépenser pour réaliser les fonctionnalités demandées. Cet article ne traite pas d’estimations, aussi je ne donnerai pas de méthode. Adoptez celle que vous souhaitez. La nature même des estimations logicielles fait que vous allez vous tromper. Ça n’est pas grave, la suite de cet article vous expliquera comment vous tromper de moins en moins à chaque projet. Si vous débutez, acceptez de perdre du temps et de l’argent à cause de vos premières estimations. Cela fait partie du jeu.

La durée est le nombre de jours calendaires entre le début du projet et la livraison. Elle peut être très supérieure au nombre de jours ouvrés dans le cas de projets en pointillés ou à temps partiel. Cela est justifié par le vieillissement du logiciel de Parnas et par le glissement des exigences d’Henderson : plus le temps passe, que le logiciel soit en production ou non, plus il faut déployer d’efforts pour le garder satisfaisant.

Le taux, quant à lui, représente le risque projet. C’est un taux journalier appliqué à la durée susmentionnée. Le calcul de ce taux est purement empirique : la valeur doit être assez haute pour vous permettre d’être rentable, mais assez basse pour ne pas rebuter les clients. J’ai mon taux de base, qui n’est pas celui de l’illustration et que je ne souhaite pas communiquer.

Vous noterez que ce mécanisme dissuade très vite les clients de rester en forfait simple au-delà d’une certaine complexité.

Les intérêts sont composés. On obtient le total après intérêts en appliquant la formule décrite par Wikipédia.

L’argent gagné avec les intérêts vous assure contre le risque de travailler plus qu’estimé, et donc facturé. Je pars du principe que votre client ne vous impose pas de pénalités de retard en cas de non-respect de la date de livraison.

Le forfait agile

Comment gérer des projets de plus grande envergure en artisan ? En les découpant en itérations. La réponse est universelle dans notre métier.

Le forfait agile a pour but de masquer la majorité de la complexité de l’agilité. Il s’adresse à des clients qui veulent externaliser un développement trop gros pour un forfait classique et qui sont prêts à payer un léger surcoût pour ne pas avoir à mettre les mains dans la gestion de ce projet. Il est un compromis entre l’embauche d’une équipe de développement et un forfait simple dont le prix serait prohibitif pour un gros projet.

Le forfait agile démarre comme un forfait classique : le client et le développeur s’accordent sur le contenu d’une livraison. Le développeur précise au client qu’il s’agit d’une première version qui sera augmentée ensuite. L’itération est chiffrée exactement de la même manière qu’un forfait classique. Le système d’intérêts composés dissuade naturellement le client d’opter pour des livraisons trop espacées.

Contrairement à un forfait classique, le client priorise les fonctionnalités qu’il souhaite. Une fois la date de livraison arrivée, le développeur présente au client le travail effectué. Celui-ci peut accepter la livraison ou bien demander au développeur de terminer l’itération à ses frais, sans cependant pouvoir lui imposer un délai. Ce mécanisme permet de reporter la responsabilité du calcul de la vélocité sur le développeur et de l’épargner au client. Le développeur est ainsi incité à être prudent dans la gestion de ses itérations s’il ne veut pas travailler pour rien.

Les itérations sont facturées avec les mêmes règles qu’un forfait classique. Ce seul fait représente déjà une économie substantielle par rapport à un forfait monolithique.

Déterminer les taux

Le développeur peut agir sur ce système par le biais de deux variables : l’estimation en elle-même et le taux d’intérêt à appliquer.

L’estimation requiert une expérience de pensée : imaginons que rien ne change au cours du projet, ni les spécifications, ni les langages ou les dépendances. Combien demanderiez-vous ? Il n’y a pas de réponse universelle à cette question. Vous pouvez calculer le temps que vous pensez y passer et appliquer un TJM. Vous pouvez aussi réfléchir à la somme que votre client est prêt à dépenser ou même à l’argent que doit rapporter votre logiciel. Chacun a sa méthode pour estimer. La seule règle est d’ignorer le changement, afin de ne pas appliquer une double peine au client.

Le taux, lui, vient compenser les incertitudes liées au temps. Rappelez-vous, le monde change autour de votre logiciel. Plus un logiciel est complexe, plus il a de prise au réel. Pensez à un avion, dont la traînée augmente avec la taille et le nombre d’excroissances germant de son fuselage. Il s’agit du premier critère : adaptez votre taux au logiciel sur lequel vous intervenez.

Le deuxième critère est le client. Si vous savez qu’il sera injoignable, indécis ou posera des difficultés, augmentez votre taux. Le taux est un excellent incitatif : expliquez à votre client qu’en restant joignable, il baissera le prix et il aura un logiciel plus satisfaisant, vous le motiverez bien plus qu’avec la seule pédagogie.

Le dernier critère est la présence de pénalités de retard en cas de mauvaise estimation. Cette pratique tend à disparaître, mais si vous en êtes victime, utilisez votre taux pour contrebalancer.

Réévaluer les taux

Notez minutieusement le temps travaillé sur chaque projet et comparez-le avec vos estimations. Calculez périodiquement trois indicateurs :

La différence entre les jours estimés (JE) et les jours travaillés (JT) multipliée par votre TJM donne les pertes dues au risque.
La moyenne du taux de dépassement de chaque projet. Le taux de dépassement se calcule comme suit : (JT – JE) / JT.
La somme des intérêts perçus sur l’ensemble des projets, moins les éventuelles pénalités de retard donne les recettes sur le risque.

La moyenne du taux de dépassement vous indique votre tendance à sous-estimer ou à surestimer vos projets. La solution est de mieux travailler vos estimations pour comprendre là où vous avez tendance à mal estimer le temps passé. Commencez par améliorer ce point, le paragraphe suivant ne vous sera pas utile à ce stade.

En soustrayant les pertes dues au risque aux recettes dues au risque, vous obtenez une information importante sur votre taux. Si vous avez perdu de l’argent sur le risque, tout en ayant réalisé des estimations justes, vous sous-évaluez votre taux sur au moins quelques projets. Si, à l’inverse, vous avez réalisé de gros bénéfices, cela signifie que vous pouvez vous permettre une réduction des taux d’au moins certains clients, ce qui peut d’ailleurs être un excellent argument de fidélisation.

La maintenance des projets

Ce modèle ne serait pas complet si je n’évoquais pas la maintenance des projets.

Après chaque livraison, à moins qu’une autre ne commence dans un avenir proche, proposez un contrat de maintenance périodique. Plus le temps s’écoule entre 2 maintenances, plus le risque augmente, les taux le reflètent naturellement.

Si l’itération suivante doit commencer dans un avenir proche, j’ai tendance à ne pas compter la maintenance du tout.

En cas de retard de maintenance, la même logique s’applique. Bien entendu, j’avertis régulièrement le client du danger de sa situation. Imaginons qu’un client revienne 2 ans plus tard avec un projet qu’il veut faire évoluer : la note peut être salée.

La reprise de projets

Le cas le plus épineux est incontestablement la reprise de projets développés par autrui. Ce modèle n’est pas prévu pour y faire face, bien qu’il s’agisse d’une part non-négligeable du marché actuel.

Après une première lecture du code, il m’arrive de refuser de reprendre. Lorsque j’hésite, il m’arrive de conditionner la reprise du projet à une régie transitoire. Le client paie à la journée le temps que d’arriver à déterminer un taux empiriquement, à partir de l’écart-type de ma vélocité sur plusieurs itérations du projet. Cette période me permet également de vérifier si le projet n’est pas tout simplement surendetté et déjà mort. Il serait alors malhonnête d’accepter de le reprendre, mieux vaut annoncer son décès et proposer au client d’anticiper son remplacement.

Le but est de revenir à une situation « normale », avec des estimations et un taux d’intérêt, même si la réalité peut être parfois très cruelle.

Sur ce genre de projets, je recommande une grande pédagogie concernant les taux. Expliquez au client qu’ils sont élevés car le projet que vous avez accepté de reprendre est en mauvaise posture. Expliquez-lui que le taux n’est pas une fatalité, mais un indicateur de l’état du projet à votre arrivée. Enfin, informez-le qu’il est possible de diminuer ce taux en investissant du temps à nettoyer le projet.

Notez que les sessions de pur refactoring ont un taux de zéro, afin d’inciter le client à y recourir. Les clients ne sont en général pas à l’aise avec l’idée qu’un développeur travaille pour ne rien livrer. Ce second incitatif n’est donc pas de trop pour les motiver.

Conclusion

Ce long article présente mes deux bottes secrètes pour rester rentable malgré le refus total de toute forme de régie à temps plein.

Les risques que je prends à la place de mes clients sont chiffrés et réajustés périodiquement, indépendamment de mon TJM. La clé est de ne pas mélanger les chiffres : le but d’un TJM est de payer le salaire et les charges de l’artisan, son évolution reflète le niveau d’expérience du praticien. Le but de l’estimation et de lier la valeur produite et le temps passé. Il faut un outil à part pour encaisser le risque inhérent au logiciel : les taux d’intérêt. Leur nom n’est pas vendeur, mais je n’ai pas trouvé mieux, tant le concept est familier à tout le monde. Qui n’a pas un crédit sur sa voiture ou sa maison ?

Le forfait agile permet de viser de plus gros projets que les basiques sites vitrine et autres moulinettes, de faible valeur ajoutée et dont le marché est saturé de développeurs à bas coût. Cet article n’a rien de scientifique : il s’agit de ma manière de procéder, peut-être est-elle applicable à d’autres, peut-être pas.

Ces deux méthodes ne sont pas une formule magique pour faire de l’argent. Ce sont des outils incitant le client et le développeur à avoir une attitude mutuellement profitable à propos de leur logiciel. Enfin, je rappelle que tout ce qui a été décrit ici n’existe qu’adossé à une clause contractuelle garantissant au client la résolution à vos frais des bugs sur une certaine période. Sans elle, vous serez tenté de prendre des raccourcis douteux pour augmenter vos marges.

On the relation of refactoring and software defects

Thu, 25 Aug 2022 00:00:00 +0000

🐛 Le refactoring agit comme un répulsif à bugs. Le nombre de défauts par commit décroît avec le nombre de refactorings dans les commits précédents. C’est la conclusion d’une étude basée sur le minage de projets open-source.

🧑‍💼 Ce n’est pas le seul avantage du refactoring, mais celui-ci a le mérite d’être compris facilement par les managers.

SOURCE

Ratzinger, Jacek & Sigmund, Thomas & Gall, Harald. (2008). On the relation of refactoring and software defects. Proceedings - International Conference on Software Engineering.

Exploratory study of Overhead in Lean/Agile Software Development

Tue, 23 Aug 2022 00:00:00 +0000

🧹 Lean prône la chasse au gaspi parmi ses pratiques fondamentales. Lean Software n’y échappe pas, les Poppendieck ont dressé une liste exhaustive des gâchis dans le processus de développement de logiciels. Sowrabh Mummadi continue cette oeuvre en traquant les frais généraux (overhead), forme plus vicieuse de gâchis.

4️⃣ En étudiant la littérature existante, il liste 4 formes d’overhead, ainsi que leurs effets et les avantages à en réduire l’importance.

👉 Les frais de management, pouvant être dus à une méthode trop lourde ou à des sprints trop courts.

👉 Les frais de coordination, survenant quand un gros produit nécessite la coordination de nombreuses équipes.

👉 Les frais de process, dûs à un trop grand nombre de documents dans les méthodes traditionnelles, ou de membres dans les méthodes agiles.

👉 Les frais de communication, quand les outils de communication ne sont pas adaptés entre les équipes ou avec les clients.

🥗 Une cinquième catégorie regroupe les frais n’appartenant à aucune autres, comme les frais de revue, de débug ou de documentation. C’est dommage car la plupart d’entre eux auraient pu être regroupés sous l’étiquette “development overhead”.

SOURCE

Sowrabh Mummadi, Exploratory study of Overhead in Lean/Agile Software Development, May 2021, Blekinge Institute of Technology

The Difficult Art of Combining Design Patterns with Modern Programming Languages

Thu, 18 Aug 2022 00:00:00 +0000

🩹 Les langages de programmation et les design patterns ont une relation compliquée. Déjà à l’époque du Gang of Four, Peter Norvig signalait que la plupart des patterns n’étaient que des rustines autour de langages trop pauvres. Les lambda des langages fonctionnels dispensent d’utiliser des factory, par exemple. Certains langages supportent nativement certains patterns et d’autres non ? Trop binaire et réducteur nous répond Eirik Emil Neesgaard Årseth.

🎨 A une vision binaire, il répond en classifiant les relations entre langages et patterns en 4 groupes, dans son mémoire de master (!). Ceertains langages incluent certains patterns dans leur syntaxe, nativement. D’autres absolument pas. Entre ces deux extrêmes, certains langages facilitent certains patterns sans les proposer pour autant. Par exemple, Javascript et son système de types facilite grandement le pattern Prototype. Enfin, certains langages ne proposant pas le support d’un pattern sont rattrapés par leur bibliothèque standard. Que serait C# sans Linq, par exemple.

🦽 Alors, les patterns sont-ils des prothèses pour des langages déficients ? Certains, assurément, mais il est abusif d’employer cette formule pour l’ensemble. Alors que les patterns créationnels sont presque tous des features manquantes, l’auteur prend le pari que les patterns structurels sont là pour de bon.

SOURCE

Årseth, Eirik Emil Neesgaard. The Difficult Art of Combining Design Patterns with Modern Programming Languages. Master thesis, University of Oslo, 2020

An Introduction to Software Architecture

Tue, 16 Aug 2022 00:00:00 +0000

🏗️ Aussi étrange que cela paraisse, l’architecture logicielle n’est pas une discipline unifiée ou clairement définie. Une des définitions est celle donnée il y a 30 ans par Garlan et Shaw. Pour eux, l’architecture est la réponse à la complexité de certains logiciels, qu’un bon design ne peut plus juguler. Il faut alors ajouter une couche d’abstraction.

⛔ L’architecte ignore volontairement le code, encapsulé dans des blocs de design. Chaque bloc, nommé composant, interagit ou n’interagit pas avec les autres, selon des règles définies par l’architecte. L’ensemble de ces règles d’architecture détermine la forme du système. L’architecture, pour Garlan et Shaw, consiste à sculpter le système par des règles, qui viennent restreindre la manière dont peuvent se connecter les composants.

🪠 Un exemple ? Obligez les composants à avoir x entrées et y sorties dans un format standardisé. N’autorisez que les connecteurs reliant l’entrée d’un composant à la sortie d’un autre. Vous obtenez une architecture Pipes&Filters omniprésente dans la BI, le low-code ou les shells Unix.

👁️ La vision de Garlan&Shaw donne des règles sur la manière dont les composants ne doivent pas agir. Aux développeurs de les respecter. Elle s’oppose à l’architecture positive, qui inverse la logique : l’architecte dit comment les composants doivent interagir, explicitement. Ces deux visions donnent deux types d’architectes très différents. L’architecte négatif pose des règles, l’architecte positif détermine à chaque instant le comportement des équipes.

SOURCE

Garlan, David and Mary Shaw. “An Introduction to Software Architecture.” Advances in Software Engineering and Knowledge Engineering (1993). DOI: 10.1142/9789812798039_0001

A survey on software smells

Thu, 11 Aug 2022 00:00:00 +0000

🏛️ J’aime les classifications. Alors quoi de mieux qu’un papier classifiant les classifications des odeurs du code ? C’est ce que proposent 2 chercheurs … grecs. Débat de philosophes ou vrai outil ? Analysons leurs résultats.

☣️ Ils ont recensé plus de 200 (!) odeurs du code dans la littérature existante, rangés dans 14 classifications différentes. Pour les chercheurs, toutes ces classifications peuvent être regroupées en 4 cohortes selon qu’elles classifient eles odeurs selon :

👉 Les principes qu’elles violent

👉 Les effets qu’elles produisent

👉 Les types qu’elles touchent (data, interfaces, etc.)

👉 Leur granularité (intra-classe, design, architecture, etc.)

🐜 Cette clarification n’est pas le seul résultat de ce travail de fourmi ! En comparant les travaux des chercheurs, ils ont noté plusieurs problèmes :

🔴 Peu de chercheurs différencient odeur et antipattern avéré.

🔴 Les définitions de certaines odeurs sont contradictoires entre les papiers.

🟡 La détection et la contextualisation automatique de celles-ci est au mieux balbutiante.

🟡 Nous n’avons pas de preuve solide corrélant odeur et baisse de productivité.

🌋 Les odeurs du code sont un champ de recherche très actif, il faudra encore des années avant d’en voir la maturité.

SOURCE :

Tushar Sharma, Diomidis Spinellis, A survey on software smells, Journal of Systems and Software, Volume 138, 2018, Pages 158-173, ISSN 0164-1212, DOI:10.1016/j.jss.2017.12.034.

Comparing four approaches for technical debt identification

Tue, 09 Aug 2022 00:00:00 +0000

🔎 Quels sont les meilleurs outils pour identifier la dette technique* ? Certains repèrent des odeurs du code, d’autres des violations de modularité, d’autres encore des violations d’usage des patterns tandis qu’une dernière catégorie repère des défauts connus.

🧩 Tous et aucuns ! Les problèmes que ces outils identifient se recouvrent très peu, il vaut mieux les cumuler.

* Le terme de dette technique désigne ici la complexité accidentelle du code, non la prise de dette au sens ou l’entend Ward Cunningham. Le terme aurait pu être mieux choisi.

SOURCE

Zazworka, N., Vetro’, A., Izurieta, C. et al. Comparing four approaches for technical debt identification. Software Qual J 22, 403–426 (2014). DOI:10.1007/s11219-013-9200-8

Why Large IT Projects Fail ?

Thu, 04 Aug 2022 00:00:00 +0000

😱 Chaque jour qui passe, le besoin réel à l’origine de vos spécifications évolue. Les spécifications, purs documents légaux, sont figées jusqu’à la prochaine livraison. Plus celle-ci est éloignée du recueil du besoin plus le produit sera décevant pour l’utilisateur. C’est le Glissement des Exigences (Requirements Drift) d’Henderson.

🚀 Ce phénomène est vicieux car très progressif en apparence. Si 0,1% de votre spécification devient obsolète chaque jour par rapport au besoin, les coûts de développement d’un produit satisfaisant auront rapidement doublé !

💡 Le glissement des exigences n’est pas seulement une reformulation de la première loi de Lehman, c’est une explication.

🔃 La morale de l’histoire : plus vous faites des itérations courtes, plus vous vous remettrez souvent en phase avec le besoin réel de votre client, moins le projet débordera.

SOURCE

Henderson, Peter B. “Why Large IT Projects Fail.” (2010).

Value and benefits of model-based systems engineering (MBSE): Evidence from the literature

Tue, 02 Aug 2022 00:00:00 +0000

🗺️ Qui n’a pas eu à l’école ce prof convaincu que dans l’avenir, il suffira de dessiner un diagramme UML pour créer un système ? L’intendance suivra. Cette idée, nommée Model-Based Software Engineering (MBSE) est venue remplacer les tombereaux de documents qui servent encore de source de vérité dans de nombreuses entreprises. Une revue de littérature de 2021 vient jeter un pavé dans la mare : il n’y a aucune preuve de l’efficacité de cette pratique.

💨 En démêlant le millier de papiers sortis sur le sujet, Henderson et Salado ont découvert très peu de preuves solides. 360 papiers affirment un bénéfice que 2 seulement mesurent objectivement. 36 “observent”, 240 “perçoivent” et 109 référencent un autre papier. L’homme qui a vu l’homme qui a perçu le loup !

❗ Pire, parmi les bénéfices prétendus de MBSE, des contradictions sont présentes et les chercheurs ne s’accordent pas sur une définition claire.

📣 La NASA ou L’International Council on Systems Engineering font de MBSE le standard de la profession pour 2025 sur la base de l’abondance des publications en sa faveur, mais la quantité est-elle la qualité ? Notre discipline a encore du chemin a faire vers la rigueur scientifique.

SOURCE

Henderson, K, Salado, A. Value and benefits of model-based systems engineering (MBSE): Evidence from the literature. Systems Engineering. 2021; 24: 51– 66. DOI:10.1002/sys.21566

The business value of agile software development: Results from a systematic literature review

Thu, 28 Jul 2022 00:00:00 +0000

💣 L’intérêt de l’agilité ne réside pas dans son meilleur respect des délais et des coûts. La recherche n’a d’ailleurs jamais affirmé que l’agilité ferait mieux que les méthodes dites “traditionnelles” à ce sujet. Un groupe de chercheurs allemands démontre grâce à une revue de littérature que la “valeur métier” de l’agilité dépasse de loin la simple performance économique :

😎 A un niveau individuel les développeurs se sentent plus motivés et impliqués dans leur travail

🏉 Les équipes sont plus soudées et interagissent mieux

🏢 L’entreprise tend à se réorganiser plus facilement

📊 Les process tendent à être plus souples et performants

🤩 L’agilité est une culture de la satisfaction client, non une méthode de conduite de projet.

❌ Pour enfoncer le clou, ils remarquent que les gains de performance attribués à l’agilité sont en réalité parfaitement corrélés à des pratiques distinctes de celle-ci :

🏭 Le refactoring réduit le nombre de bugs, le temps de débug et la performance du code

🧪 Les tests intensifs et le pair programming réduisent la densité de défauts des logiciels

🕯️ Les rituels augmentent la cohésion et la communication de l’équipe

🪢 Y a-t-il un intérêt à rassembler sous l’étiquette “agilité” des pratiques et une culture disparates ? Oui selon les chercheurs, car toutes ces pratiques forment un tout où chacune renforce l’efficacité des autres. Ils valident une intuition déjà exprimée il y a 30 ans par eXtreme Programming.

SOURCE :

Meckenstock, Jan-Niklas; Hirschlein, Nico; Schlauderer, Sebastian; and Overhage, Sven, “The business value of agile software development: Results from a systematic literature review” (2022). ECIS 2022 Research Papers. 24. https://aisel.aisnet.org/ecis2022_rp/24

A controlled experiment in maintenance: comparing design patterns to simpler solutions

Thu, 21 Jul 2022 00:00:00 +0000

🏹Les design patterns sont-ils overkill par rapport à ce qu’ils apportent ? Tout dépend de la situation, nous répond une étude allemande. Dans certains cas ils alourdissent un code qui ne demande qu’à être laissé tranquille, dans d’autres ils sont une solution élégante.

👨‍💻 Seule l’expérience du professionnel permet de juger efficacement de la pertinence d’un pattern par rapport à une solution n’en comportant pas. Encore faut-il que ledit professionnel respecte 2 conditions :

👉 Connaître les patterns

👉 Ne pas les déifier

♻️ Je recommande pour ma part de développer les deux options « quick&dirty », sous forme de prototype jetable, afin de dissiper les doutes sur la meilleure solution.

🔰 Chose notable, l’étude a été réalisée sur des professionnels confirmés, non sur des étudiants.

SOURCE :

L. Prechelt, B. Unger, W. F. Tichy, P. Brossler and L. G. Votta, « A controlled experiment in maintenance: comparing design patterns to simpler solutions » in IEEE Transactions on Software Engineering, vol. 27, no. 12, pp. 1134-1144, Dec. 2001, doi: 10.1109/32.988711.

Bad Smells in Software – a Taxonomy

Tue, 19 Jul 2022 00:00:00 +0000

🦨 Il est temps de ranger les odeurs du code ! Perdu par leur trop grand nombre et par leur manque de formalisation, le chercheur Mika Mäntylä s’est attelé à les classifier dans sa thèse qui figure au rang des classiques. Son classement a même été repris par des sites grand public comme Sourcemaking ou Refactoring Guru.

💩 Les Bloaters désignent les objets qui sont devenus trop gros pour pouvoir être appréhendés par notre esprit. Méthodes longues, God Classes, mais également plus étonnant, Primitive Obsession et Data Clumps.

📦 Tout ce qui contrevient aux principes de l’orienté-objet est rangé dans la catégorie Object Orientation Abusers. Les switchs, champs temporaires, refus d’héritages y figurent, avec les duplications d’interfaces.

⛓️ Les odeurs ralentissant ou entravant le changement sont nommées Change Preventers.

🗿 Tout ce qui est inutile, mort ou contrevenant au principe YAGNI est un Dispensable.

🪢 Le couple Message Chains/Middle Man, est appelé Encapsulators.

🖇️ Les Couplers, eux, créent du couplage superflu, donc néfaste, entre les classes.

🪄 Cette classification a des défauts dont était déjà conscient Mäntylä : catégories pour 2 odeurs, odeurs ne rentrant dans aucune. Il s’agit d’un outil perfectible, mais pas dépassé depuis 20 ans à ma connaissance.

SOURCE

Mäntylä, Mika & Vanhanen, Jari. (2003). Bad Smells in Software – a Taxonomy and an Empirical Study.

Bad Smells in Software – Software Maintainability

Fri, 15 Jul 2022 00:00:00 +0000

👎 La maintenance des logiciels n’existe pas, dans les faits. C’est une conséquence des lois de Lehman. Pour un logiciel, maintenir son contenu fonctionnel intact, c’est déjà décliner. Pour le chercheur Mika Mäntylä, il faut oublier l’idée de maintenance au profit de la notion d’évolution.

♻️ Le vocabulaire de la maintenance du logiciel, hérité de la maintenance industrielle (adaptative, perfective, corrective) n’est pas pertinent pour décrire le cycle de vie des logiciels. En effet, la maintenabilité n’est pas, comme pour un pont ou une route, la capacité à rester identique, mais bien la capacité à évoluer.

🧑‍🏫 Si la maintenance évolutive est une arnaque sur le plan contractuel, elle est la routine dans le fonctionnement des logiciels. Beaucoup de pédagogie est nécessaire pour le faire accepter aux clients.

SOURCE

Mäntylä, Mika & Vanhanen, Jari. (2003). Bad Smells in Software – a Taxonomy and an Empirical Study.

Comment testez-vous ?

Wed, 13 Jul 2022 00:00:00 +0000

Sur les projets neufs

Pour tous les projets neufs, je pratique TDD, qui n'est pas un élément négociable (sauf rares cas). Plus précisément, je pratique Outside-In Diamond TDD, qui offre une plus grande souplesse que la traditionnelle pyramide de tests, qui doit être désapprise par la profession.

Notre pain quotidien, c'est le test d'acceptation isolé ou test fonctionnel. Il détaille les clauses du contrat que nous avons passé ensemble en de multiples affirmations que je reprendrai périodiquement avec vous afin de m'assurer d'avoir bien cerné votre besoin.
Les tests contractuels ou d'intégration, décrivent le comportement que nous avons fixé ensemble au début d'une itération. Je leur donne une valeur juridique, ces tests valident la conformité des travaux à votre demande initiale.
Les tests de plus haut niveau (smoke tests, end-to-end tests) viennent démontrer le bon fonctionnement de la solution en interaction avec le monde extérieur. Ils me servent également de démonstration, lorsque je vous livre une itération.
Je ne suis pas contre l'utilisation de tests plus fins, comme les tests unitaires. Ils ont hélas été trop utilisés par une partie de la profession, provoquant la rigidification du code et dégoûtant une partie des développeurs de l'écriture de tests. Aussi, je les utilise que sur des parties critiques du code, où la manière de procéder importe autant que le résultat obtenu (performances, algorithme précis, cryptographie, etc.).

Sur les projets legacy

J'adopte la définition de Michael Feathers. Le Code Legacy est tout code non-testé qui m'est confié sans pouvoir partir rapidement à la poubelle. Dans les cas où j'accepte de reprendre un tel code, il est exclu, sauf si votre budget est colossal, de l'assainir complètement d'un coup. Le code ajouté ou modifié sera testé comme du code neuf. Le code préexistant sera sécurisé à l'aide de tests plus grossiers (smoke test) selon vos besoins, le niveau de confiance que vous souhaitez et votre budget.

Une fois repris et étayé, votre code devra être progressivement assaini. Un budget mensuel devra être établi à ce titre, il ne servira qu'à réduire l'endettement de votre application, donc à faciliter les développements futurs. Un bon budget de maintenance représente une charge non-négligeable sans pour autant gréver votre rentabilité. Il n'est pas de l'argent investi à perte, mais bien la garantie que le logiciel dans lequel vous avez investi tant d'efforts ne décède pas un beau matin, trop endetté pour pouvoir évoluer au rythme de vos besoins.

En cas de défaut

Je garantis qu'aucun bug ne reviendra après sa résolution. Pour cela j'utilise les tests de défaut. Pour chaque bug constaté, un test est écrit afin de le reproduire. Puis le code est modifié afin de faire passer ce test. Ainsi le bug corrigé ne peut pas revenir sous cette forme sans que je n'en sois informé.

Ne faites-vous pas de la surqualité ?

Wed, 13 Jul 2022 00:00:00 +0000

Si pour vous, surqualité signifie "fonctionnalité payée, mais non demandée", la pratique de TDD nous en préserve. Nous écrivons ensemble les tests qui définissent le comportement votre logiciel. De retour à l'atelier, nous écrivons le code minimal capable de faire passer ces tests. La simplicité est notre maître mot.

La perfection est atteinte, non pas lorsqu'il n'y a plus rien à ajouter, mais lorsqu'il n'y a plus rien à retirer.

La surqualité peut également désigner un code "trop propre" dans la bouche de certaines personnes. Nous avons fait il y a longtemps de deuil du code parfait, qui n'existe pas. En revanche, nous ignorons ce que signifie un code "trop propre". Un code propre est un code ayant une réponse optimale au changement. Un code peut s'encrasser et réduire la vélocité des développeurs. L'existence du cas inverse est hypothétique.
Un code "trop propre", si une telle chose est possible, serait donc un code qui facileterait au-delà du raisonnable son édition future ? Nous le prenons comme une bonne nouvelle, pas comme de la surqualité.

Quelles sont vos sources ?

Wed, 13 Jul 2022 00:00:00 +0000

La formation initiale d'un développeur est très vite caduque. Nous défendons l'obligation de formation continue pour l'ensemble de notre profession, donc nous commencons par nous l'appliquer à nous mêmes.
Trois sources permettent à l'Atelier de proposer les pratiques les plus reconnues :

Les ouvrages de maîtres de la professions, socle impérissable.
La littérature scientifique, étai des connaissances.
L'expérience, notre maîtresse en artisanat.

Ces trois sources mêlent actualité brûlante et prise de recul, sujets à la mode et validation des acquis, confirmation de nos pratiques et armes contre le biais de confirmation. Lorsque nous intervenons chez vous, vous avez le droit de nous demander nos sources.

Qu'entendez-vous par "Pas de régie" ?

Wed, 13 Jul 2022 00:00:00 +0000

Les raisons en sont expliquées sur le blog. J'arrête le télétravail.

Pour l'expliquer autrement, plus une mission s'étale dans le temps, plus nous exigerons d'autonomie. Les missions courtes (1 mois ou moins) en présentiel sont possibles, mais au-delà, le présentiel devra se raréfier.

Comprenez également que nous ne sommes pas des prestataires. L'indépendance n'est pas qu'une affaire de lieu de travail, mais également une autonomie en matière d'horaires et de calendrier. Sauf impératif (réunion, formation, livraison, etc.), nous ne rendons de compte à personne concernant notre agenda, seule la date de livraison que nous avons négociée et les jalons nous sont opposables.
Nous servons en règle générale plusieurs clients à la fois : un seul client en développement (l'activité est prenante), mais une multitude en conseil, formation, maintenance et autres activités. Nous ne pouvons pas nous permettre d'être bloqués à 100% plus de quelques semaines.

Ce schéma est une bonne représentation de ce qu'il est possible de faire. Une mission ne peut pas pas être à la fois plein-temps, sur site et long-terme. Les missions que vous nous proposez doivent s'inscrire dans ce triangle. Par exemple :

En jaune, la mission Méritis SIRH était moyenne-durée, occasionnellement sur site, à ²/₃ temps en raison de formations planifiées sur la période.
En rouge, la mission OxaControle dure depuis près de 3 ans à la fois sur chantier et en remote, mais en pointillés très espacés.
En bleu, les formations en école sont récurrentes chaque année et presque totalement en présentiel, mais de courte durée (quelques jours à 2 semaines) et à temps partiel (ces journées/semaines sont rarement remplies intégralement).
En vert, le développement du Pont SEPA-Chargebee était presque à plein temps pour tenir les délais. Je ne me suis pas déplacé du tout sur site. La mission a duré 3 mois ½ au total.

Quelle est votre pédagogie ?

Wed, 13 Jul 2022 00:00:00 +0000

Ma pédagogie est très pratique, à travers la répétition de katas et la réalisation de projets en situation semi-professionnelle.
En plus de croire fermement que la pratique encadrée par un maître est la seule école du développeur, j'ai été traumatisé par ces diaporamas de 1200 slides, subis encore aujourd'hui par trop d'étudiants. Je ne veux pas être ce genre de formateur.
Je ne rejette pas la forme magistrale pour autant, mais celle-ci vient plutôt introduire une matière, préciser des notions ou encore enseigner des connaissances théoriques nécessaires à l'exercice suivant.

Je pense qu'un bon enseignement est constitué de 20% de théorie, 20% de démonstration et 60% de pratique.

Où enseignez-vous ?

Wed, 13 Jul 2022 00:00:00 +0000

Partout en France, tant que l'établissement défraie. Habituellement, je me rends sur le lieu de mes cours pour des durées d'une semaine à un mois.
J'ai déjà enseigné à Arras, Toulouse, Montpellier, Lyon, Nantes et Bordeaux ainsi.
Nous demandons simplement aux reponsables pédagogiques de regrouper au maximum les cours.

Avec quels langages travaillez-vous ?

Wed, 13 Jul 2022 00:00:00 +0000

Réponse courte : tout est possible, mais .NET est notre plateforme de prédilection.
Réponse longue : nous préférons les langages orientés objet de haut niveau. Java, C#, C++ ou PHP nous sont familiers. Nous n'avons pas souhaité inclure cette liste dans notre présentation générale pour ne pas focaliser nos clients sur ce point. Les langages sont nos outils, nous utilisons le plus adapté pour chaque problème. Si nous devons nous mettre à niveau sur un langage, les délais avant livraison s'allongeront de manière transparente, il n'y aura pas de coût caché de formation à votre charge.

Êtes-vous compétent en Front-End ?

Wed, 13 Jul 2022 00:00:00 +0000

Ce site pourrait servir de réponse. Il est fonctionnel et sobre, peut-être trop sobre d'ailleurs. Nous pouvons élaborer des interfaces simples, mais nos talents en UI/UX s'arrêtent là. Nous pouvons cependant collaborer avec un intégrateur ou un développeur spécialisé dans les interfaces graphiques si vos besoins dépassent nos compétences.

J'ai déjà réalisé une estimation de temps, la respecterez-vous ?

Wed, 13 Jul 2022 00:00:00 +0000

Tout projet est défini par quatre variables : le temps, les ressources (ou coût), la qualité et le périmètre. Travailler avec un Atelier logiciel comme nous en bloque déjà deux.

Nos ressources sont limitées et même si elles ne l'étaient pas, 9 femmes ne font pas un enfant en un mois (Loi de Brooks).
Sauf pour des projets très spécifiques, nous ne transigeons pas sur la qualité, ce serait vous desservir.

Un choix s'offre donc à vous :

Nous livrons à l'échéance que vous avez définie, un logiciel fonctionnel, apportant de la valeur, mais au périmètre incertain.
Vous préférez ne pas fixer de délai et attendre que l'ensemble de votre logiciel soit prêt. Nous pouvons fournir un ordre de grandeur, rien de plus.

L'arbitrage entre l'envergure et les délais vous appartient complètement. Nous nous engageons à être parfaitement transparents sur les deux autres variables, à travers une tarification horaire ou journalière. Nous aidons nos clients à faire le choix le plus sécurisant pour eux.

Do you speak english ?

Wed, 13 Jul 2022 00:00:00 +0000

We can work in english as developers. We cannot teach nor audit yet as it requires extended understanding of implicit meanings. We plan to spend some months in an anglo-saxon country to improve our english.

Pouvez-vous baisser vos standards pour respecter mes délais ?

Wed, 13 Jul 2022 00:00:00 +0000

Nos standards sont des garde-fous, pas un dogme. Nous passons outre dans certains cas :

Les prototypes.
Les logiciels one shot.
La dette technique.

Un prototype est un logiciel Quick&Dirty permettant de réaliser une démonstration, un POC ou de tester une hypothèse avant la réalisation d'un vrai logiciel. De même que vous ne prendriez pas la route au volant d'un concept car, nous interdisons contractuellement à nos clients de déployer en production un prototype. Ils ne doivent servir qu'à sécuriser vos choix futurs. Un logiciel prototype ne respecte aucun standard de qualité ou de sécurité, donc il peut être produit très rapidement pour un coût modeste. L'équivalent dans l'automobile est le modèle de terre cuite qui sert aux premiers essais en soufflerie. Il permet de valider le dessin final, mais ne roulera jamais.

Un logiciel one shot est un morceau de code qui n'est pas destiné à durer dans le temps. Il est produit pour un but précis, avec une date d'expiration définie à l'avance, dont dépendront les standards de qualité. Les cas les plus fréquents sont les convertisseurs de données ou "moulinettes", servant le temps d'une migration. Nous produisons de tels logiciels, mais refuserons tout contrat de maintenance ultérieur à leur sujet.

La dette technique concerne les logiciels que nous développons déjà à vos côtés. Elle consiste à accélérer le développement d'une fonctionnalité dont vous avez besoin rapidement, contre un temps plus long de "réparation" ensuite. La dette technique est similaire à la dette monétaire. Nous ne prêtons que temporairement, pour un temps défini à l'avance. Une dette ne peut pas servir à en couvrir une autre. Contracter une dette implique des intérêts. En d'autres termes, nous pouvons temporairement produire plus vite, au prix d'une "blessure" dans le code qui handicapera les développements futurs tant qu'elle n'est pas soignée. Soigner la blessure prend plus de temps qu'il n'en aurait fallu pour réaliser les choses proprement dès le départ. En bref, la dette technique vous permet de raccourcir le délai de livraison d'une fonctionnalité, en échange d'un temps de "repos" plus tard.

Quelle est votre définition de la qualité ?

Wed, 13 Jul 2022 00:00:00 +0000

Un logiciel de qualité est un logiciel qui vous satisfait. Notre tâche en tant que professionnels est de bâtir des logiciels qui répondront à ce critère tout au long de leur durée de vie, que nous travaillions encore ensemble ou non. Lorsque l'on parle de qualité pour un bâtiment ou un véhicule, on s'attend à quelque chose qui puisse conserver sa fonction initiale le plus longtemps possible. Un bâtiment de qualité est durable et réparable. Le monde du logiciel n'obéit pas aux mêmes lois.

Le développeur Roy Osherove disait de la programmation informatique qu'elle est l'art de bâtir des châteaux de vent. Hunt&Thomas parlent plus volontiers de l'art de recueillir et formaliser des connaissances. Les deux définitions portent le même message : un code de qualité n'est pas de marbre, il est au contraire le plus perméable au changement possible. Votre métier évolue sans cesse, vos connaissances s'affinent, votre stratégie doit répondre aux enjeux mouvants d'un monde en perpétuel mouvement. Un bon logiciel ne freine pas ces processus naturels, mais s'y adapte. Voici pour nous l'enjeu de la qualité logicielle.

Je travaille en cycle en V, peut-on s'entendre ?

Wed, 13 Jul 2022 00:00:00 +0000

Je n'ai jamais entrendu parler d'un projet logiciel figé, ni dans ma carrière, ni dans la littérature. Pendant le développement de votre application, la vie continue, votre métier évolue et pire : le développement de votre logiciel va nous amener inévitablement à vous poser des questions auxquelles vous n'aviez pas pensé. Il est presque sûr que ces questions vont amener une nouvelle vision de vos besoins. Pour ne rien arranger, il nous arrive également d'être force de proposition.

Je suis conscient que la culture du cycle en V est fortement ancrée dans certaines entreprises et que le management y tient. Je peux m'y adapter à condition que l'on me laisse la possibilité de travailler par itérations de mon côté. Je vous livrerai régulièrement de la valeur, comme si je travaillais en agilité. Vous êtes libre de l'intégrer ou non, ce qui vous permet une transition en douceur si vous le souhaitez.

Cette manière de travailler suppose que je sois en contact permanent avec un référent métier capable de me préciser ce que les spécifications éventuelles ne disent jamais. Je ne travaille pas sans tests automatisés, car ils sont les clauses du contrat que nous passons ensemble. Vos expert devra être en capacité de valider ces tests.

Je préfère être honnête avec mes clients. Peut-être existe-t-il des développeurs capables de tenir des engagements de qualité sans poser ces conditions. J'en suis bien incapable. Je sais d'expérience que je suis incapable de développer de bons logiciels si ces deux critères ne sont pas remplis.

Partition testing does not inspire confidence

Tue, 12 Jul 2022 00:00:00 +0000

🤠 Dans la vie il y a deux types de testeurs : ceux qui utilisent l’aléatoire et ceux qui partitionnent. Ceux qui utilisent de l’aléatoire trouvent des bugs. Ceux qui partitionnent augmentent leur confiance.

🧠 Partitionner consiste à sélectionner soigneusement les valeurs utilisées lors des tests, contrairement à l’aléatoire qui les teste virtuellement toutes, sur la durée.

🎲 Dans un papier déjà ancien (1990), Hamlet et Taylor réaffirment que, moyennant une puissance de calcul que nous n’avons pas encore en 2022, le test aléatoire est la Rolls, car il permet de trouver plus de bugs.

🚵‍♂️ Attention cependant à ne pas caricaturer. Une Rolls consomme énormément et ne sert à rien sur les chemins de terre que l’on appelle « phase de spécification » !

🪧 Pour résumer grossièrement un papier que je vous recommande de lire :

1️⃣ Commencez par des tests partitionnés afin de définir votre domaine.

2️ « Hackez » les valeurs choisies pour vos tests dans le but de trouver des bugs.

3️⃣ Seulement dans un troisième temps, passez en aléatoire pour détecter des bugs résiduels.

🐛 Si chaque type de test est à sa place, les bugs seront bien gardés.

SOURCE

D. Hamlet and R. Taylor, « Partition testing does not inspire confidence (program testing), » in IEEE Transactions on Software Engineering, vol. 16, no. 12, pp. 1402-1411, Dec. 1990, doi: 10.1109/32.62448.

How Development and Personality Influence Scientific Thought, Interest, and Achievement

Thu, 07 Jul 2022 00:00:00 +0000

🤓Existe-t-il des traits de personnalité et des conditions de développement prédisposant à être scientifique ? Il semble que oui !

🛬 Vous avez 3 fois plus de chances de faire partie de l’élite scientifique de votre pays si vous êtes enfant d’étrangers.

♀️ Si vous êtes une fille sensibilisée aux sciences après l’adolescence, vous avez moins de chance d’en faire votre métier.

🚸 Un scientifique a de grandes chances de s’être intéressé aux sciences avant 12 ans.

🥇 Les premiers-nés sont en général plus conservateurs scientifiquement que les suivants dans la fratrie.

🤬 Être consciencieux, franc, dominant ou avoir confiance en soi diminuent les chances de s’intéresser aux sciences.

⌨️ Je suis à la recherche d’une étude similaire pour les développeurs !

SOURCE

Feist, Gregory J.. “How Development and Personality Influence Scientific Thought, Interest, and Achievement.” Review of General Psychology 10 (2006): 163 – 182. DOI:10.1037/1089-2680.10.2.163

Motivated Humans for Reliable Software Products

Tue, 05 Jul 2022 00:00:00 +0000

😌 Vous voulez des développeurs productifs ? Fichez-leur la paix en leur épargnant les réunions et les sollicitations incessantes (notifications, téléphone, etc.). Ne les surchargez pas. Ainsi ils pourront entrer plus souvent dans un état de concentration propice à leur art.

📢 Les Open Space ne semblent pas propices non plus à la concentration. Le papier date de 1997, il ne pouvait donc pas évoquer le télétravail, mais celui-ci pourrait être un moyen de laisser les développeurs tranquilles lors des phases où ils ne doivent pas être sollicités.

🥼 Bon sens ? Peut-être, mais avec de la science le message passe toujours mieux.

SOURCE

Frangos, S.A. (1997). Motivated Humans for Reliable Software Products. In: Gritzalis, D. (eds) Reliability, Quality and Safety of Software-Intensive Systems. IFIP — The International Federation for Information Processing. Springer, Boston, MA. DOI:10.1007/978-0-387-35097-4_7

An exploratory study of the impact of antipatterns on class change- and fault-proneness

Thu, 30 Jun 2022 00:00:00 +0000

🧂 A-t-on des preuves que les antipatterns sont vraiment générateurs d’erreurs ? Oui, et ils sont même corrélés à du code qui est changé plus souvent (avec le risque de le casser, donc).

⛏️ Ce résultat a été obtenu par une équipe italo-canadienne, en minant le code de projets open-source. Cette technique a permis de grandes avancées dans les sciences du logiciel, mais depuis Lehman, on sait que ces résultats sont à prendre avec prudence : l’open-source ne suit pas les même lois que le développement commercial.

SOURCE

Khomh, Foutse, Massimiliano Di Penta, Yann-Gaël Guéhéneuc and Giuliano Antoniol. “An exploratory study of the impact of antipatterns on class change- and fault-proneness.” Empirical Software Engineering 17 (2011): 243-275. DOI:10.1007/s10664-011-9171-y

Architectural Styles and the Design of Network-based Software Architectures

Thu, 09 Jun 2022 00:00:00 +0000

🌐 Si Tim Berners-Lee est le papa du Web, alors le parrain en est Roy Fielding. Sa thèse 👇 devrait être lue par tout développeur web. Dans le chapitre 4, notamment, il définit avec précisions les problèmes que doit résoudre l’architecture dont le web a cruellement besoin en l’an 2000 : REST.

💥 Posons le décor : dans les années 90 il est évident que le web va sortir largement du monde de la recherche et que les usages personnels et commerciaux vont faire exploser la non-architecture existante. L’ancien monde est mort, il faut une architecture qui soit décentralisée pour être capable d’encaisser le boom d’Internet.

🦑 Le défi est ambitieux : l’architecture du Web doit permettre l’interconnexion de machines hétéroclites (terminaux, serveurs, supercalculateurs, etc.). Les informations sont encore plus diverses : textes, images, vidéos, ainsi que tous les formats inconnus que l’avenir réserve.

🚧 La barrière à l’entrée doit être minime, car le web est en plein boom : un standard qui n’est pas simple sera rejeté. Cela signifie des références pouvant être communiquées avant même l’existence de la ressource, simplement et entre humains. Il faut que tout soit du texte, afin que l’outillage réseau existant permette de tester.

🧩 Enfin, tout doit être déployable de manière indépendante, les ressources, les serveurs ou les références. Seule la décentralisation peut encaisser une telle charge.

🏅 Un pari fou ? Dans le prochain post, nous verrons comment Fielding a relevé le défi, en proposant l’architecture REST.

💯 Le défi que le Web doit relever au début des années 2000 paraît insurmontable. Pour ne pas exploser, il faut lui concevoir une architecture compatible avec tous les formats, tous les appareils, décentralisée, mondiale, extensible et simple à utiliser.

🏆 Il faut trouver le graal de l’architecte. Rien de moins que ça. Quand Roy Fielding soutient sa thèse en 2000, il ne livre pas un misérable bocal à anchois, mais bien une architecture de maître, REST, basée sur un principe terriblement efficace : la scalabilité anarchique.

😶‍🌫️ Le paradigme de l’informatique du XXème siècle est la centralisation. Un système est sous contrôle d’une autorité centrale et tous ses éléments sont ordonnés à la même fin. Avec l’émergence d’un réseau global, ce paradigme mène à un effondrement.

1️⃣ Tous les clients ne peuvent pas maintenir à jour une liste de tous les serveurs et réciproquement.

2️⃣ Il n’est pas possible de faire confiance à une autre machine sans authentification.

3️⃣ L’authentification dégradant la scalabilité, le web doit nécessiter le moins de confiance possible.

🅰️ Roy Fielding nomme ce principe « scalabilité anarchique ». Chaque nouvel acteur peut exister sans avoir à demander d’autorisation aux autres. Les autres réagiront à sa présence a posteriori, selon leurs propres règles. Ce principe est à la base du Web moderne, même si le contrôle américain sans partage en a gâté les principes.

☘️ Qui n’a pas entendu parler de REST ? Beaucoup de gens en réalité, car l’architecture de Fielding a été terriblement mal interprétée et enseignée. Encore un leprechaun, mais aussi la marque d’un échec : Fielding n’a pas réussi à atteindre la simplicité qu’il souhaitait pour son architecture.

🔌L’idée de REST est d’atteindre la scalabilité anarchique par la définition d’une interface commune à tous. Chacun implémente comme il le souhaite son application, pourvu que l’interopérabilité respecte quelques principes simples.

1️⃣ Client-Serveur : REST s’occupe de faire transiter la donnée, l’afficher n’est pas son affaire tant la matière est spécifique à chaque client.

2️⃣ Stateless : aucune requête ne doit dépendre du contexte stocké sur un serveur. Toutes les informations de contexte nécessaires doivent être contenues dans la requête elle même.

3️⃣ Cachable : tout échange compatible doit pouvoir être mis en cache. Cette propriété n’existe pas dans un système non-Stateless. En REST/HTTP la cachbilité se signale par le verbe utilisé.

⚠️ Les années 2000 ont largement piétiné ces deux derniers principes. Les langages à session (Java et PHP en tête) ont violé le principe du Stateless, le manque de formation des développeurs a achevé toute idée de cache efficace.

🛬 Déjà esquintée à sa sortie par l’opacité de ses 3 premières règles pour les débutants, REST a définitivement perdu son public avec les 3 suivantes. L’architecture de Fielding est certainement brillante, mais certainement pas simple, comme il la souhaitait. L’enseigner est d’ailleurs un calvaire.

4️⃣ Interface Uniforme. REST définit seulement un contrat commun, charge aux développeurs de l’implémenter comme bon leur semble.

5️⃣ Architecture en couches. REST demande que le contrat commun soit dans une couche dédiée, qui appelle ensuite le véritable système.

😵 Ces deux règles auraient été comprises, si REST avait défini ce « langage commun » comme étant HTTP dès le départ. Or ça n’est pas le cas. REST/HTTP est seulement une implémentation majoritaire de REST. Dans la thèse de Fielding, ces points étaient simplement trop abstraits pour la majorité des développeurs, débutants ou non.

6️⃣ Code à la demande. Une application REST doit pouvoir fournir aux clients un snippet de code permettant de l’appeler, dans le langage de leur choix.

💀 Cette contrainte, décrite dès le départ comme « optionnelle » n’a en réalité jamais vraiment fait partie de REST. J’ai l’intuition que Fielding s’est dès le début rendu compte qu’il était allé trop loin.

🧟 REST était trop ambitieux. L’avenir nous dira s’il peut exister une architecture à la fois simple et universelle, ce que n’est pas l’architecture de Fielding. Ses mauvais clones ont rapidement remplacé l’idée originale, faisant de ce coup de génie un autre Leprechaun.

SOURCE

Fielding, Roy T.. “Architectural Styles and the Design of Network-based Software Architectures »; Doctoral dissertation.” (2000).

Design patterns impact on software quality : Where are the theories ?

Tue, 07 Jun 2022 00:00:00 +0000

⁉️ Les Design Patterns ont-ils une influence positive sur la qualité des logiciels ? Si quelqu’un vous affirme que les patterns sont obsolètes ou au contraire, qu’ils sont indispensables, il manque clairement de prudence. La recherche n’avait pas tranché en 2018 et de nombreuses questions restent aujourd’hui sans réponse.

🌫️ Nous connaissons beaucoup de propriétés des patterns. Des centaines d’études de cas, positives et négatives, s’accumulent depuis 30 ans dans les tiroirs des chercheurs. De ce brouillard, rien de clair n’est encore sorti, sinon des recommandations limitées, sans aucun caractère général et universel.

💎Que faut-il donc faire ? En attendant que la recherche tranche, ce qui peut prendre des décennies, le plus prudent est de se fier à l’expérience des maîtres. Elle n’est pas unifiée, elle se contredit, mais elle est encore ce qui fonctionne le mieux.

🏺Cette complémentarité, je la nomme Evidence Based Software Craftmanship. La tradition, que chaque génération trie en fonction de ce que la science éclaire.

SOURCE

Khomh, Foutse & Guéhéneuc, Yann-Gaël. (2018). Design patterns impact on software quality: Where are the theories?. 15-25. 10.1109/SANER.2018.8330193.

Toward a Catalogue of Architectural Bad Smells

Thu, 02 Jun 2022 00:00:00 +0000

🦨 Existe-t-il des « odeurs du code » au niveau architectural ? 4 chercheurs californiens proposent une première liste, qui ne sera validée qu’à la condition de les relier à des anti-patterns architecturaux connus.

👉 Connector Envy : Un Composant réalise des opérations normalement propres à un connecteur (Conversion, Coordination, Communication, Facilitation).

👉 Scattered Parasitic Functionality : Plusieurs composants sont chargées de la même fonctionnalité haut-niveau. Il s’agit souvent d’une manifestation d’un Crosscutting Concern.

👉 Ambiguous Interfaces : Les interfaces ne sont pas explicites, c’est à dire qu’un composant communique avec un autre en utilisant des canaux génériques, sans avoir typé les échanges.

👉 Extraneous Adjacent Connector : Il existe plus d’un connecteur reliant deux composants entre eux. Par exemple un appel direct et un bus.

SOURCE

Garcia, J., Popescu, D., Edwards, G., Medvidovic, N. (2009). Toward a Catalogue of Architectural Bad Smells. In: Mirandola, R., Gorton, I., Hofmeister, C. (eds) Architectures for Adaptive Software Systems. QoSA 2009. Lecture Notes in Computer Science, vol 5581. Springer, Berlin, Heidelberg. DOI:10.1007/978-3-642-02351-4_10

Improving evolvability through refactoring

Fri, 27 May 2022 00:00:00 +0000

🦨 Les odeurs du code sont passées dans la jargon courant des développeurs. A tel point qu’elles ont eu des déclinaisons. Les change smells par exemple, sont des odeurs que l’on ne remarque qu’en analysant l’historique des commits.

🕵️ Les chercheurs nous proposent le « Man In The Middle », où une même classe est modifiée sur la majorité des commits, même s’ils n’ont rien à voir fonctionnellement.

🗃️ On retrouve également le « Data Container », qui se remarque paire la présence d’un binôme de classes toujours modifiées ensembles, l’une portant des données, l’autre des comportements.

🔧 Les chercheurs n’ont pas établi un protocole vraiment solide pour vérifier la solidité de leur proposition, mais l’idée mérite d’être méditée par les développeurs et les éditeurs d’outils.

SOURCE

Jacek Ratzinger, Michael Fischer, and Harald Gall. 2005. Improving evolvability through refactoring. SIGSOFT Softw. Eng. Notes 30, 4 (July 2005), 1–5. DOI:10.1145/1082983.1083155

An empirical study about the effectiveness of debugging when random test cases are used

Tue, 24 May 2022 00:00:00 +0000

🔢 La génération semi-aléatoire de tests unitaires plaît beaucoup aux managers. S’il était possible de détecter les bugs sans que les développeurs n’aient à tester, on pourrait livrer plus ! Une équipe italienne a voulu le vérifier.

🐛 L’aléatoire obtient de bons résultats pour identifier des bugs qui seraient passés hors des mailles des tests classiques. Le débug est légèrement plus difficile que sur des tests manuels, ce qui est compensé par la facilité de créer de tels cas de tests.

🐱‍💻 Ces résultats ne remettent certainement pas en cause l’intérêt des tests fonctionnels ! Ils restent nécessaires dans tous les cas. Cependant, l’aléatoire est un bon moyen d’éviter les raisonnements ad-hoc et de véritablement « hacker » son code à la recherche de bugs.

🧑‍🎓 Seul bémol du papier : toutes les expériences ont été faites avec des étudiants.

SOURCE

Ceccato, Mariano, Alessandro Marchetto, Leonardo Mariani, Duy Cu Nguyen and Paolo Tonella. “An empirical study about the effectiveness of debugging when random test cases are used.” 2012 34th International Conference on Software Engineering (ICSE) (2012): 452-462. DOI: 10.5555/2337223.2337277

L'informatique de Claude Pair

Thu, 19 May 2022 00:00:00 +0000

👴 « Une découverte scientifique ne porte jamais le nom de son auteur ». Ainsi s’énonce la Loi de Stigler, qui n’a d’ailleurs probablement pas été inventée par Stigler. Cette loi s’applique parfaitement à l’informaticien Claude Pair. Ce précurseur de la science des langages de programmation est largement oublié aujourd’hui malgré une carrière riche en inventions capitales.

🧮 Si je vous parle de pile, de récursivité, de types, de structures de données ou d’analyse syntaxique, première étape de toute compilation ? Ou encore de compilateurs de compilateurs, yacc étant le plus célèbre ?

⚖️ Tous ces outils omniprésents dans nos langages modernes sont des inventions de Claude Pair, bien qu’elles lui soient rarement attribuées. Ses anciens étudiants, feu Marion Créhange (première doctorante en informatique) en tête veulent lui rendre justice depuis vingt ans.

📝 Je vous invite à lire l’article qui a servi de source à ce post, il est très accessible.

SOURCE

L’informatique de Claude Pair Marion Créhange, Pierre Lescanne et Alain Quéré: N°18, Novembre 2021, pages 91-116 DOI:10.48556/SIF.1024.18.91

Flavors : A non-hierarchical approach to object-oriented programming

Tue, 17 May 2022 00:00:00 +0000

🍨 Parmi les tentatives pour remédier aux défauts de l’héritage, les mixins figurent en bonne place. Ce concept, créé entre 1979 et 1982 a survécu de nos jours, mais inspira aussi d’autres mécanismes comme les traits, les méthodes d’extension ou les méthodes d’interface.

🔷 Les mixins se présentent comme une solution au problème du diamant, casse-tête à la fois sémantique et pratique courant en POO.

🪟 Dans une interface graphique, vous avez des fenêtres. Certaines ont des labels, d’autres non. Certaines ont des bords, d’autres non. De qui hérite une fenêtre à bords avec label ?

❌ Les deux solutions instinctives sont l’héritage multiple et l’usage de patterns. Les deux apportent de la complexité et ne sont pas satisfaisantes sémantiquement. Une fenêtre n’est pas une fenêtre à bords et une fenêtre à label. C’est une fenêtre, avec des bords et un label.

🎨 Les mixins permettent cela. Sémantiquement, ils expriment une inclusion, non un héritage. Un même objet peut inclure plusieurs flavors, dont le mélange créé le mixin. Ces flavors peuvent hériter d’autres flavors, mais en aucun cas être instanciés seuls.

🤯 L’inconvénient de ce système est de laisser une grande place aux conventions, ce qui augmente la charge mentale qui pèse sur les développeurs et les équipes. En outre, ils ne protègent aucunement des paradoxes logiques comme le Diamant de Nixon.

SOURCE

Cannon, Howard I.. “Flavors : A non-hierarchical approach to object-oriented programming.” (2007).

L'artisanat est-il excluant ?

Thu, 12 May 2022 00:00:00 +0000

Parler d’artisanat, de savoir-faire ou pire, de maîtrise, choque certains. Les artisans du logiciel seraient les « gatekeepers de la tech » comme j’ai pu le lire récemment. Ceux qui le pensent ont parfaitement raison, mais prennent l’antipathie et le manque de bienveillance de certains gardiens pour une injustice structurelle ou pire, une discrimination intolérable liée à l’existence de la porte.

Il est bon qu’il y ait des portes. Pour illustrer mon propos, je vais prendre un exemple qui ne diffère du sujet qu’en degré, non en nature. Imaginez qu’un passager, épris de Saint-Exupéry, décide de pénétrer dans le cockpit d’un avion en plein vol. Un pilote, mièvre ou inconscient, lui laisse alors le manche et prend sa pause. L’équipage et les passagers auront raison de s’insurger, qu’il y ait eu crash ou non ! La liberté individuelle de cette personne a gravement supplanté le bien commun.

La porte manquante de cette histoire n’est pas celle du cockpit, mais un réflexe social : toute personne normalement constituée aurait dû s’insurger. Aucune autorité n’a accrédité notre pilote en goguette. Personne n’a joué le rôle de proxy fiduciaire entre notre homme et la société. En somme, personne n’a exclu cet inconscient, probablement bienveillant, certes, mais inconscient quand même. Cette non-exclusion a gravement atteint au bien commun, au moins virtuellement.

Hommage aux victimes du crash de Germanwings à l’aéroport de Düsseldorf.

Les plus perspicaces remarqueront que des pilotes dûment accrédités ont déjà causé de nombreux décès, certainement plus que les voyageurs égarés entre deux rêves. Cet argument est malhabile pour deux raisons :

Thomas Salme est un faux-pilote suédois, qui a réussi a voler 13 ans sans licence. Il n’a provoqué aucun accident.

D’une part, car il faudrait comparer les taux de crashes, non les chiffres bruts. Sur l’ensemble des avions volant de manière régulière, quel pourcentage s’est crashé suite aux erreurs ou aux envies suicidaires du pilote ?
D’autre part, car l’échantillon de faux-pilotes est trop faible, faute d’être facilement mesurable. Combien d’avions ont volé, quelque soit l’issue, pilotés par des Thomas Salme ? Pas assez pour tirer des conclusions.

Quel rapport avec le développement me direz-vous ? Aucun si vous programmez un jeu de plateformes sur mobile ou toute autre application n’ayant pas de conséquences graves en cas d’échec. Pire, réguler ces marchés pourrait écarter stupidement des génies non-diplômés, comme Lucas Pope par exemple. Le crash du jeu vidéo des années 80 montre que le marché sait parfaitement réguler certains secteurs, qui se passent bien de barrières à l’entrée.

A l’opposé, peut-être aurait-il fallu des règles de l’art opposables dans des affaires comme le Therac-25, qui a irradié mortellement des patients, ou comme Louvois, qui a jeté des familles dans l’angoisse. Les artisans ne disent pas autre chose, même s’ils sont en désaccord sur la manière d’y parvenir.

Un principe de responsabilité

Le naufrage du Costa Concordia, archétype de l’anti-professionalisme.

Sur les navires, puis plus tard dans l’aéronautique, un principe est gravé en lettres d’or. En cas de problème et même s’il n’est pas coupable, le capitaine est présumé responsable. Nulle ambiguïté. Le bougre n’est dédouané que si preuve est faite qu’il n’a pas dérogé aux règles de son métier. Même s’il en avait reçu l’ordre de sa hiérarchie (ça n’est pas le cas), le capitaine du Costa Concordia n’aurait pas dû approcher si près des côtes. Il a enfreint cette règle et en porte seul la responsabilité (ainsi que de son attitude pendable ensuite).

L’accréditation est un proxy fiduciaire : le passager de l’avion n’a ni les capacités, ni le temps de juger de la capacité de son pilote. De même pour le client qui fait appel à un développeur pour lui créer un outil. L’accréditation désigne aux yeux de la société celui qui a la capacité d’être responsable, car il est au courant des règles de son art.

La confiance que l’on place dans une accréditation dépend de la fiabilité des discriminants. Ce mot fait peur, mais il désigne les critères et épreuves ayant pour but d’exclure ceux qui ne sont pas ou plus aptes à être accrédités (donc responsables). Un discriminant trop faible ou corrompu brisera progressivement ce lien de confiance. Par exemple, les pilotes accrédités par certains pays n’ont pas le droit de voler dans l’espace aérien occidental, car leur formation est insuffisante.

Un discriminant qui n’est pas fréquemment réévalué finit également par déchoir. Pensons au chirurgien dont les vieux nerfs tremblent. Il n’est pas devenu inutile à la société, incapable de servir le bien commun. Il est simplement l’heure pour lui de prendre sa retraite. Porter ce titre serait tromper le patient. Moins définitive, mais tout aussi stricte doit être l’interdiction d’exercer pour le pilote qui n’a pas volé depuis longtemps ou, c’est mon avis, le développeur qui refuse de se tenir au courant des pratiques de cybersécurité.

Le coût des accréditations

Créer des accréditations a un coût financier et social important. La liberté individuelle d’exercer une profession est limitée gravement par l’obligation d’être accrédité. Ce seul point oblige les défenseurs des professions règlementées à ne limiter leurs prétentions qu’aux matières graves.

Le plus connu des 15 ordres professionnels en France.

Si l’accréditation est contrôlée par une institution, il faut ajouter le coût de celle-ci. Il est loin d’être anecdotique : 85 millions par an pour l’Ordre des Médecins, par exemple. Cette somme doit être justifiée par le service rendu à la société. Quel est le moins cher socialement : avoir un ordre professionnel avec tous les risques de népotisme, de lobbying abusif et de corruption qu’ils comportent, ou laisser les charlatans exercer librement et ne condamner qu’a posteriori les margoulins ?

Les titres sont un accréditation légère, adaptée aux professions ne nécessitant pas de remise à jour fréquente. Est-ce le cas pour le développement ?

La question est exactement la même pour les développeurs. Le mauvais code et ses conséquences justifie-t-il le coût social important d’une accréditation ? De quel type doit-elle être ? Un simple label d’excellence ? Un titre soumis à examen ? Un chef d’œuvre ? Une inspection périodique ? Un véritable ordre monopolistique et obligatoire pour exercer ? Divers degrés existent, là encore.

Les accréditations sont un mécanisme social de gestion du risque. Une société trop crispée aura tendance à n’en tolérer aucun, ce qui entraîne la sur-réglementation néfaste à l’innovation. A l’inverse, tout tolérer revient à tirer au sort quel passager de l’avion sera le pilote du jour. Les voies socialement bénéfiques se trouvent quelque part entre les deux.

L’opportunité ou non de règlementer une profession ne peut qu’être le fruit d’un calcul politique. C’est à dire une équation dont l’unité de mesure est le bien commun.

Conclusion : Exclure avec justice, pour un plus grand bien

Tentative de symboliser la profession de développeur par Pauline Bergé-Bourbon

Je m’assume complètement comme « gatekeeper de la tech ». Je ne cache pas ma position en faveur d’un Ordre des Développeurs, car je pense que le développement de logiciels est une activité suffisamment risquée pour nécessiter une accréditation. Je pense aussi que les conditions de cette accréditation doivent être fixées par tous les praticiens, non par quelques influenceurs autoproclamés « maîtres-artisans ». D’où ma position en faveur d’un incorporation obligatoire de la profession.

J’encourage chaque lecteur à être en désaccord avec moi, selon la valeur qu’il accorde à chaque membre de l’équation. La liberté de pratiquer sans contrainte a-t-elle plus de valeur que les conséquences de l’échec ? Une accréditation est-elle plus risquée que de laisser la réputation des mauvais professionnels les discréditer naturellement ? A vous d’en juger.

Mon propos est de sortir du schéma idiot, partisan et binaire : EXCLUSION = DISCRIMINATION = MAL. De même que toutes les inégalités ne sont pas injustes, toutes les barrières ne sont pas contraires au bien de la société. Dans ce débat que Twitter ramène fréquemment au point Godwin, je souhaitais amener une réflexion plus sérieuse.

Aucune civilisation ne peut subsister en régulant chaque aspect de la vie au millimètre. Aucune société ne peut se former sans règles. Plus nos outils se complexifient, plus la question de la régulation de leur usage se pose. Les corps de métiers sont un des outils dont nous disposons.

The Economics of Software Development by Pair Programmers

Tue, 10 May 2022 00:00:00 +0000

💰 Un des arguments les plus employés contre le pair-programming est son coût. L’idée est simple : mettre deux développeurs sur un même PC double le coût, sans doubler la vitesse d’exécution. L’entreprise perd de l’argent !

❌ Rien de plus faux, déjà en 1975, Brooks dénonçait ce fameux mythe du mois/homme.

📊 30 ans après Brooks, 2 chercheurs ont rassemblé les chiffres issus de la littérature sur le pair programming. Ils ont effectué une simulation économique comparée. D’un côté deux développeurs seuls, de l’autre une paire. Dans tous les cas, la paire produisait plus de valeur.

📈 Les chercheurs ne sont pas allés plus loin, leur seul objectif était de débunker le faux-argument économique contre le pair programming. Ils ont en revanche noté que seul ou en paire, le développeur produit plus de valeur s’il travaille de manière incrémentale.

SOURCE

Erdogmus, Hakan and Laurie Ann Williams. “The Economics of Software Development by Pair Programmers.” The Engineering Economist 48 (2003): 283 – 319.

L'affaire Therac-25

Thu, 05 May 2022 00:00:00 +0000

Entre juin 1985 et janvier 1987, 6 personnes sont mortes irradiées à cause d’un logiciel médical défectueux. Cest l’affaire Therac-25, en tout cas telle qu’elle est résumée sur Internet. Les développeurs ont-ils du sang sur les mains ? C’est un peu court, nous allons le voir.

☢️ Dans les années 70, un premier appareil de radiothérapie, le Therac-20 fut conçu par la Compagnie Générale Radiographique (CGR) française et l’Atomic Energy Commission Limited (AECL) canadienne. Il fut un succès : aucun accident et d’excellents résultats thérapeutiques. Malgré cela, CGR et AECL se séparèrent, la conception du Therac-25, successeur du Therac-20 fut donc exclusivement canadienne.

🗃️ Le Therac-25 consiste en un portage du logiciel du Therac-20, de conception française, donc sans l’aide de ses développeurs d’origine, sur un nouveau matériel. Il s’agit de code assembleur, bien moins portable que nos langages modernes.

🤦 Le Therac-25 devait réduire les coûts et l’encombrement, en fusionnant une machine de radiothérapie et un accélérateur de particules. L’ensemble des contrôles de sécurité, redondants entre le software et le hardware sur le Therac-20, sont désormais confiés uniquement au logiciel. En 1983, il est installé dans 11 hôpitaux, sans aucun test indépendant. Les autorités le voient comme un simple Therac-20 mis à jour.

🤥 Une première vague de défauts a lieu en 1985, dont un fut mortel. Le fabricant, bien que mis au courant par les médecins, a nié avoir eu vent de cas similaires. Les ingénieurs ont systématiquement nié la possibilité même d’un problème alors que les opérateurs hospitaliers étaient habitués aux bugs et caprices de la machine.

🎺 Bien qu’étant incapable de reproduire le problème, car ne soupçonnant pas le logiciel à ce stade, AECL a déployé un « correctif ». Accompagné d’une explication savante, il devait « réduire les chances de défaut d’au moins cinq ordres de grandeur ». Mazette.

☠️ Après un décès, enfin la FDA se réveille ! Le Therac-25 va repasser sur le banc d’essai et cessera d’être une machine de mort ! En fait non. La FDA a émis un rappel de classe II, réservé aux « situations où un matériel défectueux peut dans certains cas provoquer des blessures légères ou réversibles ». Le décès et la nature des blessures ne figurent pas au rapport.

📖 Sans aucun audit logiciel, les autorités ont demandé à AECL de modifier le manuel d’utilisation afin d’augmenter le nombre de contrôles visuels par les opérateurs.

🤑 La cause racine n’ayant pas été identifiée ou corrigée, la machine a continué de semer la mort. AECL resta dans le déni pendant toute l’année 1986, malgré 2 morts et 4 blessés. Après les modifications effectuées, la machine ne pouvait pas être défectueuse !

🩹 Un second patch fut déployé, pour prévenir de prétendues erreurs des opérateurs. Il n’a pas empêché d’autres blessures, parfois mortelles. Le ridicule fut atteint lorsque AECL recommanda de mettre du scotch sous une touche du clavier pour empêcher des saisies invalides.

👌 Il faut attendre 1987 pour que AECL sorte enfin un véritable correctif sous pression des autorités. 4 systèmes critiques ont reçu des protections hardware tirées du Therac-20. Il n’y a plus eu de blessures rapportées ensuite.

🤐 Après 2 ans à semer la mort, le Therac-25 fait enfin l’objet d’une expertise sérieuse en 1987. Les pratiques de développement sont révoltantes sur une matière aussi grave.

💸 Le management a tout fait pour faire passer un nouveau produit pour une simple amélioration du Therac-20, afin d’éviter les audits et les contrôles. Les économies ont été faites en confiant au seul logiciel des opérations critiques. Et quel logiciel !

👉 Ce logiciel fut développé sans aucune politique de tests ! Il fut testé sur simulateur afin d’éliminer les bugs les plus grossiers, c’est tout.

👉 Le code est proprement illisible et ésotérique, même pour les développeurs d’AECL.

👉 L’orgueil des développeurs les a poussés à croire leur logiciel infaillible au point de supprimer tout contrôle matériel.

👉 Des patchs ont été déployés alors même que le bug n’avait pas été identifié.

👉 Des bugs visibles ont été laissés parce que jugés « peu critiques ».

👉 Aucun suivi de la qualité et des incidents n’existait chez AECL.

🤥 A cela il faut ajouter la responsabilité de la direction, qui a nié des incidents, menti, refusé des audits et a même produit des rapports de test bidon, sans qu’aucun test n’ait été réellement effectué. Les autorités sanitaires n’ont pas bronché, minimisant des incidents mortels. A ma connaissance, aucun responsable n’a connu la prison.

⚖️ La morale de cette histoire est simple : tous les procès du Therac-25 se sont réglés en dehors des tribunaux, avec les familles ou les victimes. Tant que la malfaçon logicielle n’aura pas de sévères conséquences pénales, ce genre de pratiques subsistera. Le meilleur entraînement et les meilleures pratiques ne sont rien face à l’appât du gain.

🪦 Le Therac-25 aurait du être notre Verdun : plus jamais ça. On sait depuis que la FDA n’est pas au courant de 99% des incidents survenant dans les hôpitaux. Le nombre de décès pourrait être bien pire.

SOURCE

Leveson, Nancy G. and Clark Savage Turner. “An investigation of the Therac-25 accidents.” Computer 26 (1993): 18-41.

Ariane 5: Who Dunnit ?

Thu, 21 Apr 2022 00:00:00 +0000

🚀 4 juin 1996. Ariane 5 décolle de la base de Kourou. 37 secondes plus tard, le lanceur explose avec à son bord des expériences scientifiques. Aucun humain n’était à bord, fort heureusement. A qui la faute ? A la gestion du logiciel dans le programme.

🐛 Une exception non rattrapée a provoqué une conversion incorrecte, puis un arrêt des systèmes du gyroscope. Ce logiciel avait été porté d’Ariane 4 vers Ariane 5 sans avoir été retesté. La faute à qui ? Comme dirait Jacques Ellul, à personne car le processus était trop complexe pour désigner un coupable. Nous pouvons cependant désigner des suspects.

💥 Les développeurs ont fait une erreur. Elle était dormante sur Ariane 4 et ne s’est déclenchée qu’une fois le logiciel porté sur Ariane 5. Ils ne pouvaient pas l’anticiper, les tests étant incapables de prouver l’absence de bugs. Elle aurait pu être évitée par l’usage d’un langage plus fortement typé, mais ils n’ont probablement pas eu le choix.

🧪 Les testeurs pourraient être coupables, mais ont-ils eu le budget et le temps de revérifier tous les systèmes portés d’Ariane 4 à Ariane 5 ? Le rapport indique qu’il n’y a pas eu de tests de cette partie, sans en indiquer la cause.

🪄 Comme d’habitude c’est la faute au process, donc à personne, sauf à la responsabilité individuelle, éventuellement.

SOURCE

Bashar Nuseibeh. 1997. Ariane 5: Who Dunnit? IEEE Softw. 14, 3 (May 1997), 15–16. DOI:10.1109/MS.1997.589224

Higher Order Mutation Testing

Tue, 19 Apr 2022 00:00:00 +0000

👾 Les tests de mutation sont incapables de détecter plus que des bugs triviaux. Pour aller plus loin, il faudrait combiner plusieurs mutations par test. Cette technique se nomme HOMT, Higher Order Mutation Testing en Anglais. Le loup ? Le nombre de tests à générer est exponentiel. Comment surmonter cela ?

🧬Deux chercheurs britanniques expliquent que peu de combinaisons correspondent à des bugs potentiels. Tout le défi est de savoir lesquelles. Ils ont essayé plusieurs méthodes pour y parvenir et il semble que les algorithmes génétiques offrent les meilleurs résultats.

🤖 Tenons-nous enfin une application de l’IA au développement qui ne soit pas du marketing ? Pas si vite. Les résultats montrent aussi qu’un modèle entraîné sur un programme ne fonctionne pas sur un autre. La recherche est encore balbutiante, ces outils ne seront pas dans les mains des devs avant longtemps.

SOURCE

Jia, Yue and Mark Harman. “Higher Order Mutation Testing.” Inf. Softw. Technol. 51 (2009): 1379-1393.

An empirical study of the impact of modern code review practices on software quality

Thu, 14 Apr 2022 00:00:00 +0000

👓 Nous savons qu’une mauvaise code review baisse la qualité du code. Mais qu’est-ce qu’une bonne review ? Est-ce seulement atteignable ? Les revues formelles des années 70 ont été abandonnées au profit des analyseurs statiques et autres compilateurs avancés. Seules ont survécu les revues modernes, « légères », ritualisées, mais à l’efficacité discutée.

3️⃣ Pour une bonne revue, il faut 3 ingrédients. Si l’un vient à manquer, ça n’est pas la peine de poursuivre.

👉 Une bonne couverture. La revue doit couvrir une bonne partie des modifications. C’est souvent le seul critère retenu pour les revues modernes, d’où leur échec.

👉 Une participation élevée. Si personne ne s’intéresse vraiment au code, autant ne pas organiser de revues.

👉 Un bon niveau d’expertise. Les participants doivent être adaptés au code revu, inviter tout l’open-space n’a aucun intérêt.

🤝 Vous savez quoi ? Le pair programming garantit automatiquement et en direct la satisfaction de tous ces critères. Une revue n’a pas à être forcément asynchrone, contrairement à un mythe bien ancré*.

*Ce paragraphe est un avis personnel

SOURCE

McIntosh, S., Kamei, Y., Adams, B. et al. An empirical study of the impact of modern code review practices on software quality. Empir Software Eng21, 2146–2189 (2016). DOI:10.1007/s10664-015-9381-9

Who needs software engineering ?

Tue, 12 Apr 2022 00:00:00 +0000

👉 Qu’est-ce que le logiciel ? C’est la question que Steve McConnell a posée à plusieurs experts collaborant à l’IEEE Software en 2001. Parmi les réponses, celle de Robert Cochran a particulièrement retenu mon attention. Elle synthétise les propriétés de ce matériau que nous façonnons.

1. Le logiciel est intangible.

2. Il possède un haut contenu intellectuel.

3. Il n’est pas reconnu comme un actif par les comptables et n’est donc pas dans le compte de résultat.

4. Son développement nécessite beaucoup de main d’œuvre, organisée en équipe autour d’un projet. Les développeurs oublient souvent que peu de métiers dans le monde travaillent ainsi.

5. Il ne possède aucune distinction entre R&D et production.

6. En principe, un logiciel peut changer indéfiniment.

💡 Ces principes peuvent paraître évidents, mais je ne les ai jamais retrouvés aussi clairement listés ailleurs.

SOURCE

Mcconnell, Steve. (2001). Who Needs Software Engineering?. Software, IEEE. 18. 5 – 8. 10.1109/MS.2001.903148.

The Effects of Layering and Encapsulation on Software Development Cost and Quality

Thu, 07 Apr 2022 00:00:00 +0000

💊 Contrairement à l’héritage, l’encapsulation obtient de bons résultats en matière de qualité logicielle. Deux groupes d’étudiants ont été formés. Le premier avait le code source complet d’une dépendance, le second n’en connaissait que l’interface publique.

⏲️ Le groupe n’ayant que l’interface à disposition a mis moins de temps à développer une même fonctionnalité que celui ayant les sources complètes. Bien entendu, l’interface fournie était claire et sans effets de bord. Une interface trompeuse ou obscure aurait pu largement changer le résultat.

🧑‍🎓 Hélas, l’étude est peu significative à cause de du faible échantillon (18 personnes) et du fait qu’il s’agisse d’étudiants.

SOURCE : Stuart H. Zweben, Stephen H. Edwards, Bruce W. Weide, and Joseph E. Hollingsworth. 1995. The Effects of Layering and Encapsulation on Software Development Cost and Quality. IEEE Trans. Softw. Eng. 21, 3 (March 1995), 200–208. DOI:10.1109/32.372147

Experimental assessment of the effect of inheritance on the maintainability of object-oriented systems

Tue, 05 Apr 2022 00:00:00 +0000

↕️ Arrêtez l’héritage ! Il n’est pas nécessaire à l’orienté-objet et serait potentiellement néfaste. Un code avec héritage est plus difficile à modifier que le même code sans héritage.

📝 3 chercheurs on demandé à 4 groupes de 12 étudiants de lire différents codes, utilisant plus ou moins de niveaux d’héritage pour la même fonctionnalité. Ils leur ont ensuite soumis un questionnaire évaluant leur compréhension du code. Le résultat montre une corrélation assez claire.

🗜️ Cependant, les chercheurs notent que la taille du code est encore plus néfaste à la lisibilité. L’héritage pourrait donc être utile s’il amène de la concision. Plus d’études seraient nécessaires.

SOURCE

R. Harrison, S. Counsell, R. Nithi, Experimental assessment of the effect of inheritance on the maintainability of object-oriented systems, Journal of Systems and Software, Volume 52, Issues 2–3, 2000, Pages 173-179, ISSN 0164-1212, DOI:10.1016/S0164-1212(99)00144-2.

Cessons l'appel à Dunning-Kruger

Thu, 31 Mar 2022 00:00:00 +0000

👱‍♂️FAKE NEWS ! Depuis des années, j’utilise l’effet Dunning-Kruger pour appuyer mes raisonnements et analyser pas mal de phénomènes. Mon dernier article évoque la montagne de la stupidité. Sauf que tout cela est erroné.

🍀 Dunning-Kruger est un Leprechaun. Il n’est pas ce que la culture populaire en a compris. Chez Dunning&Kruger, pas de montagne de la stupidité, même pas de lien net entre compétence surévaluation de sa propre compétence. Ce phénomène existe, il s’agit de l’ultracrépidarianisme.

🔰Les deux chercheurs nous disent en réalité que plus une personne est compétente dans un domaine, plus elle a tendance à sous-évaluer son niveau par rapport aux autres. Rien de plus. Cet article explique parfaitement ce phénomène.

😳 Désolé à mes étudiants à qui j’ai enseigné quelque chose de faux pendant des années, où à mes collègues que j’ai ennuyé avec ce fake.

On the Danger of Coverage Directed Test Case Generation

Tue, 29 Mar 2022 00:00:00 +0000

✈️ Générer des tests automatiquement à partir d’une mesure de coverage est toujours une mauvaise idée. Pourtant c’est un standard dans l’aéronautique et le spatial, y compris sur le programme F-35.

🎲 La génération aléatoire avec régression ou la génération dirigée par coverage ne font pas mieux que le pur hasard en matière d’efficacité des tests. Cela signifie que des tests générés parfaitement aléatoirement obtiennent des résultats meilleurs (jusqu’à 2 fois) ou équivalents aux méthodes précédemment citées.

👽 Évidemment, l’étude est légèrement biaisée par l’usage de tests de mutation comme mètre-étalon, mais il est raisonnable de penser que si le coverage est incapable de créer des tests efficaces sur les défauts simples, il ne fera pas mieux que des bugs réels ou complexes.

⚠️ Les chercheurs recommandent de s’en tenir au consensus scientifique : le coverage ne doit être utilisé que comme révélateur des parties du code les moins testées. Pas plus.

SOURCE

Staats M., Gay G., Whalen M., Heimdahl M. (2012) On the Danger of Coverage Directed Test Case Generation. In: de Lara J., Zisman A. (eds) Fundamental Approaches to Software Engineering. FASE 2012. Lecture Notes in Computer Science, vol 7212. Springer, Berlin, Heidelberg. DOI:10.1007/978-3-642-28872-2_28

Code coverage for suite evaluation by developers

Thu, 24 Mar 2022 00:00:00 +0000

👾 Les tests de mutation sont utiles, mais coûteux à exécuter. Mieux vaut les réserver à l’environnement d’intégration continue. 3 chercheurs américains nous montrent que le statement coverage constitue une bonne approximation aux tests de mutation, suffisante en tout cas pour indiquer aux développeurs les parties sous-testées du code.

🎯 En effet, rappelez-vous : le coverage ne doit JAMAIS être un objectif.

SOURCES

Rahul Gopinath, Carlos Jensen, and Alex Groce. 2014. Code coverage for suite evaluation by developers. In Proceedings of the 36th International Conference on Software Engineering (ICSE 2014). Association for Computing Machinery, New York, NY, USA, 72–82. DOI:10.1145/2568225.2568278

On the effectiveness of unit tests in test-driven development

Tue, 22 Mar 2022 00:00:00 +0000

🔥 J’ai trouvé la perle rare : une étude sur TDD qui compare cette méthode à Test-Last ! La plupart ont le biais de comparer TDD vs Pas de tests. Malgré son faible échantillon, elle obtient des résultats positifs : TDD serait plus efficace pour obtenir une couverture acceptable que Test-Last.

👾 Cependant l’étude a un biais : la mesure servant à comparer les deux méthodes est le score de mutation. Or, on sait que celui-ci n’est pas totalement corrélé aux fautes réelles.

🏢 Cette étude va dans le bon sens, mais notre profession manque cruellement d’études de cas sur le long-terme, faute de dialogue entre chercheurs et entreprises. Si vous êtes manager, aidez-les ! Contactez l’université la plus proche pour leur proposer de vous étudier.

SOURCES

René Just, Darioush Jalali, Laura Inozemtseva, Michael D. Ernst, Reid Holmes, and Gordon Fraser. 2014. Are mutants a valid substitute for real faults in software testing? In Proceedings of the 22nd ACM SIGSOFT International Symposium on Foundations of Software Engineering (FSE 2014). Association for Computing Machinery, New York, NY, USA, 654–665.

Tosun, A., Ahmed, M., Turhan, B., & Juristo, N. (2018). On the effectiveness of unit tests in test-driven development. In M. Kuhrmann, R. V. O’Connor, D. Houston, & R. Hebig (Eds.), ICSSP 2018 – May 26-27 – Gothenburg, Sweden: Proceedings of the 2018 International Conference on Software and System Process (pp. 113-122). Association for Computing Machinery (ACM). DOI:10.1145/3202710.3203153

Exploring the relationships between design measures and software quality

Thu, 17 Mar 2022 00:00:00 +0000

📏 Les années 90 ont laissé derrière elles pléthore de mesures quantitatives du code : CBO, RFC, MPC, DAC, ICP, etc. Elles sont passées de mode dès la décennie suivante, faute de preuves de leur efficacité contre les bugs. On leur doit tout de même l’abandon progressif de l’héritage en orienté-objet, plus avantageusement remplacé par la composition dans la plupart de ses usages.

🔎 Le papier du jour analyse l’efficacité de différentes mesures et leur corrélation avec la probabilité de découvrir des défauts. Si les mesures d’héritage ou de couplage s’en sortent bien, les mesures de cohésion ne semblent pas donner de résultats.

🐛 Autrement formulé, si les mesures de cohésion et d’héritage sont bien corrélées à la probabilité qu’il existe un défaut dans un classe, il n’y a aucune garantie que ces défauts quantitatifs soient corrélés à de vrais bugs, qualitativement ressentis comme tel. La plupart des études des années 2000 ont confondu ces notions, ce qui les rend caduques avec le recul.

SOURCE

Briand, Lionel Claude, Jürgen Wüst, John W. Daly and D. Victor Porter. “Exploring the relationships between design measures and software quality in object-oriented systems.” J. Syst. Softw. 51 (2000): 245-273. DOI : 10.1016/S0164-1212(99)00102-8

Non-software examples of software design patterns

Tue, 15 Mar 2022 00:00:00 +0000

👨‍🏫 Certains design patterns peuvent être illustrés par des exemples réels, qui aident à les enseigner. Ainsi le commercial agit comme un Proxy pour les questions techniques, le contrôleur aérien est un Médiateur, le médecin un Visiteur, et la chaîne de commandement à l’armée est une Chaîne de Responsabilité.

💭 D’autres, sans doute trop abstraits ou liés aux propriétés particulières du logiciel (personne n’a jamais vu un maçon réaliser une toiture avant les fondations, alors que c’est le quotidien d’un développeur), manquent de tels exemples. Leur enseignement reste, encore aujourd’hui un défi.

🧠 Les exemples, bien qu’utiles, doivent cependant être utilisés avec prudence : ils illustrent bien, mais décrivent mal. Une fois initié à l’aide d’exemples, le développeur doit s’en détacher pour progresser.

SOURCES

Duell, Michael, John Goodsen and Linda Rising. “Non-software examples of software design patterns.” OOPSLA ’97 (1997).

A quoi servent les maîtres ès métiers ?

Thu, 10 Mar 2022 00:00:00 +0000

La maîtrise n’est pas un gros mot, mais un mécanisme social contre ~~l’effet Dunning-Kruger~~ et ses ravages. Le plus dangereux dans un métier n’est pas le novice, hésitant et humble, mais le débutant, qui ne sait pas encore qu’il ne sait rien, mais sait suffisamment pour croire savoir. Il est sur la montagne de la stupidité et ne doit pas être laissé en autonomie.

Dans l’ancien système corporatif, l’apprenti n’est pas ou peu autorisé à toucher aux outils, la matière est rare, donc chère. C’est heureusement terminé, au moins pendant que nous jouissons encore d’une énergie abondante. Lorsque sa capacité à ne pas gâcher la matière première est confirmée, l’apprenti devient compagnon. Ce statut dure plusieurs années, pendant lesquelles il est formé partiellement en école et partiellement par la pratique à devenir un professionnel compétent. Pour partir maître et être autorisé à créer son affaire, sans personne pour le superviser, il doit prouver qu’il est capable d’estimer correctement son niveau.

C’est cela un maître : un professionnel autonome, tant sur la pratique de son métier que sur l’auto-évaluation de ses compétences.

J’ai beaucoup d’artisans parmi mes proches, travaillant différentes matières. Qu’ils travaillent les pigments, la pierre, le bois, le plâtre ou le code source, tous s’accordent à reconnaître quels types de chantiers nécessitent la main d’un maître. Partout où la connaissance scolaire seule ne suffit pas, où l’expérience doit avoir creusé dans le socle théorique des sillons de sagesse, il faut un maître.

Là où autrui a rendu confuse la frontière entre le commencé et le terminé ; Là où le diable se niche dans des anfractuosités invisibles, que le temps creusera imperceptiblement ; Là où des bleus recrutés à la hâte partagent leurs biais cognitifs, sans modérateur pour tempérer la réaction en chaîne ; Là où l’œuvre doit survivre au temps au changement et aux hommes, il faut une main de maître, pour faire sinon pour guider.

Ce n’est pas un hasard si le rôle de maître est apparu avec les premières industries humaines, pour s’éclipser lorsque l’énergie a abondé. Nos sociétés ont le luxe de gâcher une énergie peu couteuse en éternels recommencements. L’avantage est une grande sérendipité qui favorise l’innovation. Cette stratégie est sur le point de devenir économiquement perdante, si elle ne l’est pas déjà écologiquement.

La pollinisation n’est pas valable seulement à l’échelle d’une équipe. Les maîtres doivent aller à la rencontre des juniors pour leur transmettre des parcelles de savoir.

Ayant hérité des échecs de ceux qui l’ont précédé, le maître est économe. Il ne dépense pas de matière et d’énergie à reproduire les échecs des autres. Il fait les siens et les ajoute au corpus qu’il léguera à ses apprentis. Évidemment, ce phénomène fonctionne aussi pour les fausses bonnes idées. Fausses bonnes idées qui se répandent de toutes façons, maître ou pas, contrairement aux bonnes pratiques. Le point est dans le camp des maîtres.

Quiconque regarde notre profession constate que les mêmes erreurs sont répétées encore et encore, comme une éternelle enfance qui jamais ne renie ses Peter Pan. J’émets l’hypothèse qu’il s’agit d’un manque de maîtres, où en tout cas de leur absence de contacts avec ceux qui ont le plus besoin d’eux. La plupart restent entre « gens qui ont compris », produisant certes d’excellents logiciels, mais laissent 95% de la profession à la merci du hasard des rencontres. Cette situation doit changer si nous voulons sortir notre profession de l’immaturité.

Les écoles paient en général plus mal que la formation en entreprise. Cependant, ne parler que d’argent sur ce sujet, c’est négliger la formation que nous avons nous-même reçue, à bas coût, par des maîtres eux-aussi moins payés que le marché. Il est à mon sens de notre devoir d’entretenir le cercle, que le donné compense le reçu.

Un contre-pouvoir

Le maître est une autorité. Ce mot fait peur, tant il est entaché d’illégitimité par ceux qui s’en revendiquent. Elle est pourtant cruciale dans tout groupe humain, à tous les échelons, subsidiairement.

Au plus bas niveau, prenez un débutant et placez-le face à une demande qu’il sait être néfaste à son œuvre et à celui pour qui il la réalise. Il n’a aucune autorité. Son avis ne compte pas. On lui forcera la main, sauf si son caractère le porte à l’intransigeance, ce qui est rare chez les débutants. Le pauvre hère n’a pas l’autorité de s’imposer comme expert en son domaine. Ses arguments sont balayés et sauf s’il possède une bibliographie importante lui servant d’autorité, ce qui est rarissime, il n’aura pas le dernier mot. A force d’avoir tort, il finira par se faire une raison, se « ranger » et se taire. Quelle perte pour la profession ! Le XX^ème siècle nous a pourtant appris avec Hannah Arendt que nos sociétés n’ont pas besoin de plus de petits bonshommes gris, se contentant juste de suivre les ordres sans discuter.

Gouvernement Castex : seuls 3 ministres (Véran, Dupont-Moretti, Blanquer) ont exercé un métier en rapport avec leur portefeuille dans les 10 ans qui ont précédé leur nomination. Les gouvernements précédents n’ont pas fait mieux. Mon propos n’est pas de critiquer tel ou tel parti.

Ce raisonnement et sa conclusion se retrouvent au plus haut niveau. La technocratie est à l’épistocratie ce que l’oligarchie est à l’aristocratie : un singe avec une malette nucléaire. Le gouvernement des managers, des cabinets de conseils et des « experts » n’ayant pas sué à la tâche depuis leur diplôme ne donne aucune garantie de compétence dans quelque domaine que ce soit. Ce n’est pas aux gouvernants de choisir qui doit représenter une profession auprès de l’État, mais bien aux maîtres eux-mêmes de se choisir des syndics. Ce système est aussi faillible que le sont les hommes qui le compose, mais il a sur la technocratie deux avantages : la compétence et l’autorité.

Les mauvais maîtres sont inéluctables, mais sous de bonne institutions, ils représentent et régulent efficacement un métier. Il faut bien entendu apprendre des errements du XVIII^ème et son népotisme crispé, autant que des failles des ordres contemporains. Si ce travail est correctement réalisé, le « non » d’un maître peut éviter à l’œuvre de périr et le « non » d’une profession organisée autour de ses maîtres peut faire de même pour une branche, voire la puissance d’une nation.

Cet article est la suite de celui traitant des juniors.

Realizing quality improvement through test driven development : results and experiences of four industrial teams

Tue, 08 Mar 2022 00:00:00 +0000

🧪 TDD fonctionne et ses effets positifs s’accumulent dans le temps à condition de ne pas baisser la garde et de correctement respecter la méthode. La papier n’a rien d’original, il est une étude de plus sur le sujet. Son originalité est d’indiquer une corrélation entre la compétence des praticiens et le rapport bénéfices/coûts de TDD.

🧠 Plus les développeurs sont formés, moins le temps supplémentaire passé à écrire les tests se ressent et plus les bugs sont rares. Hélas, les résultats sont statistiquement peu significatifs, à cause de la faiblesse de l’échantillon.

✅ Les papiers s’accumulent sur TDD et aucun n’est encore venu infirmer l’hypothèse que cela fonctionne très bien, avec un peu de formation et beaucoup de sérieux.

SOURCES

Nagappan, Nachiappan, E. Michael Maximilien, Thirumalesh Bhat and Laurie A. Williams. “Realizing quality improvement through test driven development: results and experiences of four industrial teams.” Empirical Software Engineering 13 (2008): 289-302.

The effects of development team skill on software product quality

Thu, 03 Mar 2022 00:00:00 +0000

🤯 Les Juniors ont tendance à produire des logiciels de moins bonne qualité que des Novices, remarquent deux chercheurs américains. Comment est-ce possible ? Deux explications :

🎖️ Les chercheurs émettent l’hypothèse que les Junior sont considérés comme des développeurs « comme les autres » par le management, ils se voient attribuer les mêmes tâches que leurs collègues Senior, sans en avoir l’expertise.

⛰️ Je postule que l’effet Dunning-Kruger n’est pas étranger à ce phénomène. Alors que le Novice tâtonne avec prudence, le Junior prend la confiance sans avoir le niveau de ses aînés, il se situe donc sur la « Montagne de la Stupidité », le pire alignement possible. En mûrissant, il comprendra qu’il ne sait rien.

SOURCES

Beaver, Justin & Schiavone, Guy. (2006). The effects of development team skill on software product quality. ACM SIGSOFT Software Engineering Notes. 31. 1-5. 10.1145/1127878.1127882.

On the Composition of Well-Structured Programs

Mon, 28 Feb 2022 00:00:00 +0000

🤬 Aucun gain de performance n’a de valeur si un programme n’est pas fiable ! Le vrai défi ne consiste pas à gratter le moindre bit ou la moindre microseconde. La priorité est d’organiser des programmes de plus en plus gros et complexes, grâce à une rigueur et des méthodes prenant en compte les limitations fondamentales de nos cerveaux. Les développeurs doivent être humbles et s’interdire de déployer des programmes qu’ils ne maîtrisent pas complètement.

💰 Économiquement, le salaire des développeurs est plusieurs ordres de grandeur plus cher que le temps de calcul. En gâcher 90% en maintenance est inexcusable.

🤦‍♂️ Ce propos n’a rien d’innovant ? C’est bien le problème, il a été écrit en 1974 par Niklaus Wirth. Rien n’a changé.

SOURCES

Niklaus Wirth. 1974. On the Composition of Well-Structured Programs. ACM Comput. Surv. 6, 4 (Dec. 1974), 247–259. DOI:10.1145/356635.356639

Enough About Process : What We Need are Heroes

Thu, 24 Feb 2022 00:00:00 +0000

🧠 Début février, je postais un article sur l’opposition entre artisanat et ingénierie. Une différence dont je n’ai pas parlé, pour ne pas alourdir mon propos, est le lien entre process et compétences.

🤖 L’industrie, que ce soit voulu ou non, remplace la compétence par le process, qui est sa version encapsulée et simplifiée pour être comprise par une machine.

🦾 L’artisanat assiste la compétence par le process, qui n’en est que l’auxiliaire.

🦸 Cette distinction fait écho à la notion d’héroïsme, telle que la souhaite Roger Pressman, dans un papier resté célèbre. Il peste contre le tout-process, qui consiste à jeter le héros dans le même sac que le hacker ou le cowboy, deux figures mal-vues, souvent à raison, dans notre métier.

✨ Notre métier n’accumule les réussites que lorsqu’une mentalité artisanale permet aux héros de prendre le leadership sur les projets, même si Pressman n’utilise pas ce terme.

SOURCE

Bach, James. “Enough About Process: What We Need are Heroes.” IEEE Softw. 12 (1995): 96-98. DOI : 10.1109/52.368273

Science and substance : a challenge to software engineers

Tue, 22 Feb 2022 00:00:00 +0000

🛑 Le travail que je réalise ici est probablement trompeur. Il y a presque 30 ans, Fenton, Pfleeger et Glass nous alertaient contre un ennemi subtil : la mauvaise science. La situation n’a probablement pas changé et ça n’est que maintenant que je découvre cet article édifiant.

🧠 Mon but avec cette veille est de privilégier l’empirisme à l’intuition. Un raisonnement même brillant ne suffit pas : il faut des chiffres, solides de préférence.

🥼 Je n’ai pas de formation scientifique et les écoles ne sensibilisent pas les étudiants à la recherche. Il me manque des bases solides et ça n’est que par intérêt pour l’empirisme (organisateur de bien des aspects de ma vie), que je me suis lancé dans ce travail d’intérêt général. J’y amène mes limites.

👁️ C’est ce « mieux que rien » qui me fait continuer. Toutefois, après la lecture de cet article, je vais veiller à améliorer progressivement ma manière d’interpréter la recherche.

🔝 Quels seraient ces axes d’amélioration selon les auteurs ?

👉 Vérifier l’adéquation entre l’expérience et l’hypothèse testée.

👉 Ne pas automatiquement croire les données issues de recherches sur des étudiants ou sur des projets conçus pour l’occasion. Il faut recueillir des données de vrais praticiens sur de vrais projets.

👉 Vérifier que les mesures effectuées sont légitimes sur les données recueillies.

👉 Vérifier la temporalité, un résultat peut être différent à court et long-terme.

👉 Vérifier la représentativité, certaines expériences sont trop courtes ou avec un échantillon trop restreint, ou biaisé.

🤑 Ce n’est que comme cela que notre profession sortira de l’immaturité et des promesses des vendeurs de solutions-miracle.

SOURCE

N. Fenton, S. L. Pfleeger and R. L. Glass, « Science and substance: a challenge to software engineers, » in IEEE Software, vol. 11, no. 4, pp. 86-95, July 1994, doi: 10.1109/52.300094.

Critical success factors for software projects : A comparative study

Thu, 17 Feb 2022 00:00:00 +0000

🔝 Tel un Youtubeur en manque d’inspiration, je vais résumer le papier du jour par un TOP 5 (le dernier va vous étonner, pouce bleu, abonnement). Quels sont les facteurs de succès les plus critiques dans un projet logiciel, selon 43 publications étudiées ?

5️⃣ Avec 22 papiers le mentionnant, le soutien du top management, incluant la confiance envers l’équipe de développement, n’est pas à négliger.

🥉 Les compétences du management et la pertinence de la méthode utilisée sont cités par 23 papiers. Si vous me suivez, j’ai déjà donné quelques pistes sur ce que la recherche en pense.

🥉 Ex-aequo, l’adoption d’un planning réaliste. Si vos devs acceptent mollement VOS estimations ou alertent qu’elles sont irréalistes, écoutez-les. Imposer une deadline relève souvent du caprice si les devs vous disent que c’est impossible.

🥈 Des objectifs clairs sont cités par 24 papiers. Trop souvent cette évidence manque. Le projet ne peut pas réussir, faute d’avoir une définition de la réussite connue de tous.

🥇 Avec 26 citations, la clarté des exigences&spécifications mérite sa place en tête. Là encore, si vous me suivez, vous savez que c’est un serpent de mer et que seule une démarche itérative et pilotée par les tests (EATDD) produit des effects significatifs.

🔧 Vous noterez qu’il n’y a AUCUN facteur technique. Les développeurs ne sont pas le facteur limitant dans le marais de sous-qualité contemporain. Le gâchis logiciel est dans les méthodes.

SOURCES

Nasir, Mohd Hairul Nizam Bin Md and Shamsul Sahibuddin. “Critical success factors for software projects: A comparative study.” Scientific Research and Essays 6 (2011): 2174-2186. DOI:10.5897/SRE10.1171

Iterative enhancement : A practical technique for software development

Tue, 15 Feb 2022 00:00:00 +0000

🔁 Le développement itératif et incrémental (IID), souvent rebrandé « Agilité », n’est certainement pas une technique nouvelle sur laquelle nous n’aurions pas de recul. Avant que l’OTAN ne créé l’ingénierie du logiciel en 1968, les développeurs ont accumulé de beaux succès avec une méthode que Basili et Turner ont synthétisée en 1975.

🦴 Tout commence avec « une implémentation initiale d’un squelette de sous-problème », autrement dit peu de choses. Les développeurs viennent ensuite dépiler des tâches présentes sur une liste, pour bâtir itérativement le logiciel.

8️⃣ A tout moment, 8 règles doivent être respectées :

👉 S’il y a une difficulté, le refactoring doit faciliter sa résolution

👉 Si les modifications ne sont pas circonscrites à un module, il faut redesigner.

👉 Même chose pour les tables

👉 Plus une itération progresse, plus la modification doit être simple à achever. Sinon il faut refacto.

👉 La durée de vie d’un patch ne doit jamais dépasser 2 itérations

👉 Le code doit être relu fréquemment à la lumière des objectifs

👉 Les outils d’aide au développement doivent être utilisés le plus fréquemment possible, pas seulement à la fin d’une itération

👉 Il faut en permanence collecter les retours utilisateurs et améliorer l’implémentation.

🗑️ Cette méthode n’a jamais cessé d’être appliquée, même si les années 80 ont préféré recourir massivement aux méthodes Waterfall, gonflant les taux d’échec et ruinant la réputation de notre profession.

SOURCES

Basili, Victor R. and Albert J. Turner. “Iterative enhancement: A practical technique for software development.” IEEE Transactions on Software Engineering SE-1 (1975): 390-396. DOI : 10.1109/TSE.1975.6312870

Object-oriented programming with flavors

Wed, 09 Feb 2022 00:00:00 +0000

🍦L’orienté-objet n’est pas né d’une traite. Son histoire est jalonnée de prototypes, qui ont pavé la voie à ce qu’il est aujourd’hui. Les flavors en font partie. Ancêtre direct des mixins/traits modernes, ils n’ont jamais été implémentés hors de LISP.

🧑‍🔬 Outre l’intérêt historique du papier, il me permet d’évoquer le creuset de ce paradigme : OOPSLA. Il s’agit d’une conférence annuelle de chercheurs en langages de programmation. Aujourd’hui fondue dans SPLASH, elle était autrefois indépendante.

🧠 En sont sortis une grande partie des papiers présentés ici et beaucoup de grands noms de la profession y ont développé leurs idées : Barbara Liskov, John Vlissides, Kent Beck, David Parnas et j’en passe.

💮 C’est à l’OOPSLA 1986 que David Moon et Howard Cannon ont proposé l’idée des Flavors. Il s’agit d’une manière de faire partager des méthodes et attributs communs entre deux classes, sans qu’elles ne dépendent d’un parent commun.

🧩 L’héritage simple est débattu depuis longtemps. L’abandon de l’héritage multiple, expérience malheureuse de C++, et l’insuffisance de la composition, jugée lourde par certains praticiens, ont abouti à l’idée de « traits » partagés par plusieurs classes sans lien hiérarchique. On les retrouve aujourd’hui en Kotlin, PHP, Ruby, Rust, Scala, pour ne citer que les principaux.

💣 Plus suprenant, C# et Java implémentent un système de traits sans l’assumer, en permettant la définition de méthodes dans les interfaces. L’idée aura mis 20 ans à percer, nul doute qu’elle ne sera pas correctement utilisée avant encore 20 ans. Tout ce qui rend passionnant ce métier en somme.

SOURCE

David A. Moon. 1986. Object-oriented programming with flavors. SIGPLAN Not. 21, 11 (Nov. 1986), 1–8. DOI:10.1145/960112.28698

Coverage and Its Discontents

Mon, 07 Feb 2022 00:00:00 +0000

Pour bien enfoncer des portes ouvertes, encore un papier sur le lien entre coverage et qualité des tests :

❌ Attacher une prime ou un objectif quelconque au coverage est la pire des idées. Elle poussera les développeurs à faire de mauvais tests.

❌ Branch-coverage, statement-coverage, etc. Aucun ne sort du lot en matière de bugs découverts.

❌ Les tests de mutation semble posséder les mêmes biais que le coverage. D’autres recherches sont nécessaires.

✔️ Le Coverage restera toujours un meilleur indicateur que le nombre de tests ou leur temps d’exécution.

✔️ Le Coverage permet de repérer les parties du code sous-testées, c’est son principal (seul ?) avantage.

💡 En résumé, utilisez le coverage pour repérer les oublis de votre politique de tests, pas comme indicateur d’absence de bugs !

SOURCES

Groce, Alex & Alipour, Mohammad & Gopinath, Rahul. (2014). Coverage and Its Discontents. 10.1145/2661136.2661157.

Opposer artisanat et ingénierie est une idiotie

Fri, 04 Feb 2022 00:00:00 +0000

Lewis Mumford (1895-1990)

L’idée que l’industrie est l’évolution nécessaire de tout artisanat est un lieu commun fortement ancré dans la mentalité contemporaine. Dans la seconde moitié du XXème siècle, une lame de fond trouvant son origine chez Lewis Mumford[i] parcourt la plupart des disciplines que l’on croyait acquises à l’industrie : architecture, mobilier et même agriculture. Elle se nomme vernacularisme [ii]et tente de réconcilier science et tradition, productivité et beauté.

Mon métier, le développement de logiciels, n’était pas né lors de l’émergence du courant vernaculaire et son inclusion dans ce débat n’intervient que dans les années 2000, avec le mouvement de l’artisanat logiciel (Software Craftmanship). Le débat fut vif entre tenants d’une ingénierie logicielle « tayloriste » et ceux d’un artisanat logiciel[iii] qui n’allait pas tarder à se séparer du mouvement Agile. L’enjeu du débat est d’imposer sa grille de lecture à l’informatique des années 70 à 90. L’échec qualitatif historique du développement logiciel, qui fait les choux gras du Standish Group[iv], fut analysé par les deux camps, chacun ayant son explication.

Les méthodes des années 70 sont un facteur d’échec certain pour la profession.

L’artisanat du logiciel, explique que le désastre trouve son origine dans l’abandon des pratiques artisanales des années 60 au profit de méthodologies en tunnel. Dans ces dernières, la valeur est le fruit d’un processus industriel rationalisé dans lequel le développeur n’a pas de rôle moteur. Cette école plaide pour une conception itérative et incrémentale des logiciels, où la petite équipe décide collectivement avec le client de l’ensemble des choix de design. Pour Paul Taylor[v], cette rhétorique est intégralement issue du vernacularisme et s’appuie sur un empirisme clairement assumé par les praticiens. La présence importante d’anciens hippies dans la profession, sensibles aux thèses de Marcuse et Illich, n’est sans doute pas étrangère à l’origine de ce courant, mais il s’agit là d’une hypothèse personnelle. A ma connaissance aucune étude de l’origine de ce courant de pensée n’a été réalisée.

Architecture vernaculaire, ou architecture sans architecte. L’analogie s’est étendue à d’autres disciplines, dont le développement.

A contrario, pour les partisans de l’ingénierie, dont les arguments sont résumés par Ivar Jacobson et Ed Seidewitz[vi], le développement a échoué par manque de rigueur dans ses méthodes. Les auteurs ne dénigrent pas les artisans, qui sont à l’origine des très belles choses. Cependant ils considèrent que tout travail artisanal est par nature inefficient, car non-répétable et donc très faiblement ouvert à l’optimisation. C’est la pratique de l’ingénierie, un « artisanat supporté par une théorie », qui permettra au développement de sortir de la crise. L’ingénierie, selon les auteurs, uniformise les pratiques des différents maîtres et des différentes écoles derrière une théorie commune.

Ce débat soulève deux questions. D’abord, l’artisan est-il si allergique à la science que ça ? Autrement formulé, accuser la transmission traditionnelle des connaissances d’aller contre la science n’est-il pas fallacieux ? Ensuite, nous étudierons le lieu commun affirmant que tout artisanat se doit de progresser en une ingénierie, toute pratique vernaculaire en une industrie et toute tradition en une science. Enfin ce papier conclura sur l’opportunité ou non pour un développeur de s’identifier à la figure de l’artisan.

L’artisan est-il un technophobe qui s’ignore ?

Au XIVème siècle, Étienne Marcel, alors prévôt des marchands de Paris, tenait le Roi de France en respect ! Celui qui était alors le chef des petits artisans et compagnons, majoritaires dans le Paris de l’époque, se savait plus puissant que le Roi, qu’il souhaitait faire contrôler par les guildes, trois siècles avant la Glorieuse Révolution Britannique. C’est en grande partie lui qui associa dans notre imaginaire les maîtres-artisans à un Moyen-Âge où ils furent tout-puissants.

Daniel Bernouilli (1700-1782); Médecin, physicien, mathématicien et astronome. Un savant polymathe typique de son époque.

Quelle chute lorsque les corps de métiers sont rayés d’un simple trait de plume le 14 juin 1791 par la Loi Le Chapelier[vii] ! Or c’est également à la fin du XVIIIème que la méthode scientifique moderne a déployé ses ailes, refermant peu à peu la période des grands savants de l’Époque Moderne. Les grands génies polymathes cèdent la place à des armées de spécialistes, physiciens, biologistes, archéologues, etc.

A cause de cette corrélation temporelle, l’imaginaire populaire associe en un tout indissociable « l’Ancien Régime », période allant du Haut Moyen-Âge à l’Époque Moderne, avec ses artisans réunis en guildes, ses mousquetaires, ses carrosses et ses perruques. La culture fantasy et médiévaliste n’a pas aidé en liant définitivement l’artisan à cette « époque ».

Or, corrélation n’est pas causalité. Cet argument ne peut pas, à lui seul, coller définitivement aux artisans une étiquette « antiscience » ou les condamner au suranné.

Un second argument contre l’artisanat consiste à accuser la transmission des savoirs par apprentissage, ou transmission par Tradition. Il lui est reproché de créer des silos nuisibles au partage universel des connaissances techniques. Oui, les maîtres-artisans avaient leurs secrets, que la fragile transmission à un seul apprenti pouvait perdre. Toutefois, ne s’agit pas d’un problème propre aux artisans, mais à toute entreprise vivant d’un savoir. Les secrets industriels, brevets et autres revues académiques hors de prix ont succédé à l’opacité des corporations, il ne s’agit donc pas d’un argument qui puisse servir contre l’artisanat seul.

Sans Alexandra Elbakyan, l’accès à la littérature scientifique mondiale serait impossible sans payer de lourdes redevances à des éditeurs dispensables.

Je défends la thèse qu’il s’agit en grande partie d’une question de technologie disponible, et qu’à niveau technologique égal, l’industrie n’aurait pas fait mieux que l’artisanat des siècles passés. Ce sont les revues scientifiques permises par les progrès de l’impression et de l’édition qui ont permis le développement des circuits de production de connaissances actuels. A notre siècle, l’accès à la littérature académique n’a jamais été aussi facile, beaucoup de revues sont consultables gratuitement, même s’il faut parfois employer des moyens plus légitimes que légaux[viii] pour cela.

De nos jours, qui veut travailler en se basant sur les faits scientifiques peut le faire, que son mode de production soit artisanal ou industriel. Tous les professionnels qui m’entourent, qu’ils soient dans l’informatique, l’art ou le bâtiment, basent leurs œuvres sur des connaissances acquises lors de leur formation initiale. Le maçon ou le charpentier connaît des rudiments de mécanique, l’enlumineur possède des bases de chimie et le développeur doit bien s’intéresser un peu aux bonnes pratiques. Aucun de ces professionnels ne peut se permettre d’être trop en retard sur les connaissances du moment. Cette observation vaut autant pour les salariés de l’industrie que pour les artisans, d’ailleurs souvent issus des mêmes formations.

C’est après les études que la question se complique. Très peu de professionnels poursuivent leur formation et rares sont ceux qui s’intéressent à la littérature académique. Tous attendent la sortie de normes contraignantes pour se former, faute d’avoir d’autres incitatifs. On observe hélas le même comportement chez les médecins, pourtant théoriquement tenus de se former en permanence. Il s’agit probablement d’une affaire de culture et les artisans sont ici logés à la même enseigne que les industriels.

Chez les développeurs, en dehors des universitaires, l’intérêt pour les travaux académiques se retrouve principalement dans le mouvement artisanal du software craftsmanship. Je possède un fort biais dû à mes fréquentations, mais je n’ai jamais rencontré de collègue réalisant une veille académique dans l’industrie, bien plus obnubilée par le dernier outil/langage/framework à la mode.

Cet autocollant humoristique pourrait taper bien plus juste que prévu.

Finalement, une fois les arguments simples épuisés, il ne reste contre l‘artisanat qu’un discours très ancien dans l’histoire des idées, opposant frontalement science et tradition, souvent en accusant cette dernière de dogmatisme, d’irrationalité ou d’immobilisme. Déconstruire ce discours occupera la seconde partie de cet article.

L’artisan n’est pas un ingénieur imparfait.

Lorenzo Cifonelli, maître-artisan tailleur. Son existence n’est pas incompatible avec celle d’une industrie du vêtement. Assurément un artisanat de civilisation.

Toutes les industries actuelles sont issues d’une discipline autrefois artisanale, quand elles ne sont pas des créations récentes. Je ne connais aucune discipline ayant parcouru le chemin inverse. Cependant, toutes les industries connues cohabitent avec un double artisanal plus ancien, qui a toujours survécu dans une logique de qualité et de haut niveau de personnalisation. Le textile, l’automobile, la boucherie ou la restauration partagent tous le point commun de posséder une industrie majoritaire qui n’a jamais éliminé ce que Bruno Lussato appelle un « artisanat de civilisation »[ix].

L’artisanat est vieux comme l’outil et ne disparaître vraiment jamais au profit de l’industrie. C’est son principal avantage qui garantit sa survie dans les périodes de vaches maigres : sa résilience. L’artisan est un généraliste d’une matière, non un spécialiste en process (ce qu’est l’ingénieur). Il ne produit pas un bien précis, mais possède une connaissance étendue d’une matière et des outils nécessaires à la façonner. En un mot, il peut s’adapter.

Monoculture = mono-débouché.

La crise du Covid confirme cette théorie : ce sont les artisans qui furent à l’avant-garde de la production de masques, bien avant que les industriels ne parviennent à réorienter leur production, quand les machines qu’ils possédaient le leur permettaient. Ce sont aussi les agriculteurs les plus diversifiés et les moins industrialisés qui ont le mieux traversé la crise (sans gaspillage d’argent public, j’entends).

L’artisan n’aura jamais l’optimisation de l’industriel, ce qui le rend moins compétitif lors des périodes fastes, pour les domaines où le bas coût en masse est une obligation. C’est par la résilience et l’adaptabilité qu’il se rattrape sur le long cours, étant moins sensible aux aléas que l’industrie. L’artisan est un producteur complet, ouvrier et cadre en une même personne, souvent en contact direct avec ses clients. Taylor remarque que cela rend la boucle de rétroaction produit très agile, l’artisan étant capable de concevoir par très petits incréments, n’ayant pas la lourdeur du process industriel à supporter.

L’artisanat n’est pas un métier, mais un mode de production, qui préexiste et coexiste avec l’industrie depuis au moins le Xème siècle. Il n’est pas une industrie baroque ou diminuée, mais bien une autre manière de produire, moins optimisée, mais plus résiliente. Industrie et artisanat ne sont aucunement mutuellement exclusifs sur une filière donnée. Toutes les filières de luxe sont des industries incluant une grande part d’artisanat en bout de chaîne. La part d’artisanat et d’industrie sur une filière est une question essentiellement politique et stratégique. Éradiquez les artisans, vous chasserez les coûts, au prix d’une absence totale de résilience et d’adaptabilité, voire d’une absence de civilisation pour Lussato. Interdisez l’industrie, vous obtenez une société mal armée pour la guerre économique et pour la guerre moderne tout court, incapable de défendre ses choix politiques face aux puissance étrangères.

Je vais plus loin : aucune filière stratégique ne peut se permettre d’être complètement industrielle ou complètement artisanale. Opposer les deux est bête, surtout dans un pays comme la France, possédant une vraie culture hybride, rayonnant à l’international par son savant mélange d’artisanat et d’industrie. Une économie-monde perd toujours à choisir l’un ou l’autre.

Exportations de la France en 2014. Un mélange d’artisanat et d’industrie. Source : Wikipedia.

Conclusion

Cette complémentarité entre artisanat et industrie se retrouve entre leurs sous-jacents cognitifs : la tradition et la science. Trop souvent (bêtement) opposés, ces deux modes de production de la connaissance sont indissociables.

Pyramides chinoises de Xixia, encore un coup des Atlantes ?

D’abord, parce qu’aucune industrie n’existe sans tradition et aucun artisanat sans science. Pourquoi l’écartement ferroviaire contemporain standard ? Parce que les essieux des chars romains ont été normalisés il y a bien longtemps[x]. Pourquoi certaines structures, comme les pyramides, se retrouvent partout sur le globe, malgré une absence d’interactions entre leurs bâtisseurs ? ~~Parce qu’une race de reptiles se déplace sous la surface terrestre depuis des millénaires.~~ Parce que les bâtisseurs, où qu’ils soient, ont déduit des lois empiriques de l’étude de la nature, bien avant l’apparition de la méthode scientifique. Celle-ci n’a pas inventé la science, elle n’a été qu’une étape vers plus de rigueur, mais tout artisanat repose sur des connaissances théoriques depuis les tailleurs de silex.
Ensuite parce que la science pure n’est pas applicable en l’état. Elle doit être appliquée pour servir aux praticiens. Appliquée à quoi ? A un corpus de connaissances, transmis de manière traditionnelle, précisément. La science vient amender et augmenter les connaissances d’un métier au fil des découvertes, mais ce sont bien des professionnels, formés par des professeurs et des maîtres, qui doivent effectuer ce travail.
Enfin, parce qu’une tradition figée ne survit pas, sauf éventuellement dans les musées. Un métier qui cesse d’amender son corpus de traditions à chaque génération meurt. En matière économique, le traditionalisme figé n’est pas viable, mais cela va même plus loin : le métier qui ne fait pas évoluer la manière dont il amende sa tradition à chaque génération n’est pas viable. A chaque génération, la manière dont science et tradition interagissent doit aussi se renouveler !

L’artisanat et l’industrie n’ont pas de différence fondamentale dans leur rapport à la science. Du moins, pas en nature, éventuellement en degré. L’artisan a éventuellement une approche plus conservatrice que l’industriel. La différence fondamentale entre ces deux personnages réside dans le mode de production, donc dans les qualités du produit final.

Un livre qui devrait faire l’objet d’études de cas pas les étudiants.

C’est exactement cette conclusion que je vais appliquer au développement de logiciels. Un artisan-développeur n’est pas un anti-ingénieur, niant les meilleures pratiques certifiées™ au profit de l’enseignement d’obscurs gourous. Il n’a pas de problème avec la science, qu’il utilise bien volontiers (plus que la moyenne des développeurs) pour garder un regard critique sur ce qu’enseigne tel ou tel membre de la communauté, maître reconnu ou simple pair.

L’artisan-développeur, surtout, n’a pas l’énorme passif d’échecs méthodologiques de ces 40 dernières années à assumer. Il était là dès les origines de la programmation, fut éclipsé à l’ère des méthodes en tunnel pour mieux renaître depuis les années 2000. La littérature académique donne raison aux artisans sur des pratiques adoptées dans leurs communautés depuis des décennies. Pire : l’impasse dans laquelle toutes les tentatives de faire du logiciel une discipline formelle, aux bases théoriques et mathématiques solides, ne semblent pas avoir de sortie.

Nous continuons de bâtir des châteaux de vent, des édifices de pensée, de manière purement empirique. La matière que nous sculptons est tellement particulière qu’il serait légitime de se demander, finalement, si ça n’est pas l’ingénierie du logiciel qui manque de sens ? Il existe quelques métiers qui ne s’envisagent pas autrement que dans une logique industrielle. Peut-être tenons-nous avec le développement un cas de métier qui n’est qu’artisanal.

Opposer artisanat et industrie à l’échelle d’une branche ou d’une nation est idiot. Cela n’exclut pas la possibilité de métiers pour lesquels l’une ou l’autre de ces formes est contre-productive. Je soutiens que le développement en fait partie, dans l’état actuel de nos connaissances.

[i] Technique et Civilisation (1934) ; Paris, Le Seuil, 1950 ; Marseille, Parenthèse, 2016

[ii] https://fr.wikipedia.org/wiki/Architecture_vernaculaire

[iii] http://manifesto.softwarecraftsmanship.org/

[iv] The Standish Group, CHAOS Report

[v] Taylor, P. (1). Vernacularism in Software Design Practice: does craftsmanship have a place in software engineering?. Australasian Journal of Information Systems, 11(1). https://doi.org/10.3127/ajis.v11i1.143

[vi] Jacobson, Ivar & Seidewitz, Ed. (2014). What happened to the promise of rigorous, disciplined, professional practices for software development?. Queue. 12. 10.1145/2685690.2693160.

[vii] https://fr.wikipedia.org/wiki/Loi_Le_Chapelier

[viii] https://fr.wikipedia.org/wiki/Sci-Hub

[ix] Lussato Bruno, La Troisième Révolution

[x] Il est tout à fait possible que cette explication elle-même, impossible à sourcer, soit une tradition. Elle existe parce qu’aucun chercheur n’est venu la vérifier, dans un sens ou l’autre. Encore une illustration du lien intime entre science et tradition.

The Impacts of Low/No-Code Development on Digital Transformation

Wed, 02 Feb 2022 00:00:00 +0000

💸 Je lis parfois des propos rageurs, souhaitant le chômage à ces incompétents de développeurs, enfin rendus inutiles par le Low/No Code (LNC). Outre le manque de charité flagrant, la recherche n’est pas du même avis : LNC et développeurs sont complémentaires, et ce pour longtemps.

🇨🇦 Le chercheur Zhaohang Yan, de l’université de Toronto, synthétise une vingtaine d’articles présentant les avantages et inconvénients des outils LNC.

✔️ Une application LNC est bien plus agile qu’un développement classique, avec un temps de développement divisé par 5 ou 10.

✔️ L’utilisation de LNC permet de libérer les développeurs des tâches à faible valeur, auxquelles peuvent se consacrer les utilisateurs, directement.

✔️ LNC offre un exutoire aux utilisateurs, moins tentés d’utiliser des outils non-conformes aux politiques de sécurité, dits « Shadow IT »

➖ Les applications LNC semblent plus maintenables que les projets classiques, mais les données sont peu significatives.

❌ Une application LNC n’est ni scalable, ni customisable. Si les briques logiques offertes par une plateforme ne permettent pas d’exprimer un besoin, développer un logiciel sera moins coûteux que de créer une chimère, infecte à maintenir.

❌ Adopter LNC c’est faire une confiance totale à une plateforme. Confiance en matière de sécurité (gros acteurs = gros intérêt des assaillants), de confidentialité (les GAFAM vivent de vos données) et de durabilité (la plateforme sera-t-elle là dans 10 ans ?). Totale, car il est très compliqué de migrer une application LNC.

SOURCES

Yan, Zhaohang. (2021). The Impacts of Low/No-Code Development on Digital Transformation and Software Development.

« Cloning Considered Harmful », Considered Harmful

Mon, 31 Jan 2022 00:00:00 +0000

🍸 DRY : Don’t Repeat Yourself. Un slogan rabâché aux étudiants du monde entier, souvent comme un dogme. Largement sorti de son sens original (ne pas dupliquer de connaissance), il devient souvent une chasse aux sorcières anti-duplication du code, créant des monstres.

🇨🇦 Deux chercheurs canadiens ont décortiqué ce problème en distinguant plusieurs buts à la duplication, chacun présentant un bilan plus ou moins positif en faveur de la duplication.

🍴 Le forking, où le clone vit indépendamment de sa source, pose très peu de problèmes, tant que les deux codebases sont régulièrement nettoyées et qu’elles n’ont pas d’interactions entre elles.

🗋 Le templating, simple copier-coller d’un snippet pour en reproduire les effets présente deux grands dangers : multiplier les coûts de maintenance et dupliquer un code buggé. Il est déconseillé sauf si les avantages contrebalancent ce choix.

🪄 La customisation est une simple inspiration, avec ou sans copier-coller, d’un code qui sera remanié ensuite pour résoudre le problème. Elle est un bon moyen de gagner du temps à court-terme, mais créé une dette technique qui devra être tracée et résorbée.

🧪 Les auteurs ne parlent pas de duplication dans les tests, qui sont un 4ème cas à ajouter au papier : on sait qu’il vaut mieux un test dupliqué qu’un test obscur, la clarté primant sur tout le reste.

📝 Chacune de ces catégories est subdivisée plus finement, je vous encourage à lire le papier pour avoir une vision plus fine du sujet que LinkedIn ne le permet !

SOURCES

Hunt, Thomas, Pragmatic Programmer, The: From Journeyman to Master. Pearson. 2000.

Kasper, C. and Godfrey, M.W. (2008) Cloning Considered Harmful, Considered Harmful: Pattern of Cloning in Software. Empirical Software Engineering, 13, 645-692 DOI:10.1007/s10664-008-9076-6

Does code decay ? Assessing the evidence from change management data

Wed, 26 Jan 2022 00:00:00 +0000

☠️ Le code se décompose-t-il ? Pas au sens biologique, car il est une pure information, immuable. Cependant, tout développeur le sait, un code qui prend de l’âge devient plus difficile à éditer, coûte plus cher et se constelle de bugs. Ce phénomène est inévitable autant bien le connaître !

🩺Ses symptômes sont connus :

👉 Le code devient bouffi et complexe, les développeurs s’engluent dans des modifications interminables.

👉 Les bugs se multiplient et la satisfaction des utilisateurs baisse.

👉Les commits n’ont plus de cohérence (shotgun surgery)

👉 Les développeurs ne vont plus droit au but, ils beurdassent* le code pour espérer arriver à leurs fins.

🕳️ La décomposition du code doit alerter les développeurs : ignorer cette odeur est extrêmement dangereux et se soldera inévitablement par la mort du projet à moyen ou long terme. Si rien n’est fait, une part de plus en plus grande de la productivité de l’équipe ira dans le trou noir des intérêts de la dette, jusqu’à la paralysie complète.

♻️ Une lueur d’espoir persiste cependant : il existe une cure de jouvence facile d’accès qui se nomme refactoring.

* Traduction libre de « code churn » via ce verbe saintongeais. Amitiés aux québécois qui en ont hérité.

SOURCES

S. G. Eick, T. L. Graves, A. F. Karr, J. S. Marron and A. Mockus, « Does code decay? Assessing the evidence from change management data, » in IEEE Transactions on Software Engineering, vol. 27, no. 1, pp. 1-12, Jan. 2001, doi: 10.1109/32.895984.

The magical number seven: still magic after all these years ?

Mon, 24 Jan 2022 00:00:00 +0000

🪄 Pourquoi le chiffre 7 est-il si magique ? Selon le psychologue Miller, il est une bonne approximation de la capacité de la mémoire immédiate humaine sur des tâches génériques (auxquelles le sujet n’a pas été entraîné). Mais en quelle unité s’exprime cette capacité ? En éléments ? Non ! En chunks.

🧠 Un chunk est une « case » dans notre mémoire. Pour Miller et la psychologie cognitive, lorsque nous devons accomplir une tâche, notre cerveau doit charger des éléments en mémoire, afin de les manipuler pour obtenir un résultat. Pour un développeur, ce sont des arguments d’une méthode, des classes ou tout autre artefact du code.

📦 Chez un novice, chaque chunk correspond en général à un élément. L’intérêt du concept apparaît avec l’entraînement : un individu apprend rapidement à « compresser » les informations pour augmenter la densité d’éléments par chunk. Le cerveau possède un grand nombre d’outils pour cela, comme l’abstraction, le mapping avec des éléments stockés dans la mémoire à long terme ou encore l’utilisation de représentations visuelles ou sonores.

📊 En réalité 7 (6.5 précisément) est une moyenne, mais en réalité la capacité de nos cerveaux s’échelonne entre 3 et 15 éléments, suivant une courbe en cloche.

🤝 Ces travaux nous aident à comprendre nos cerveaux et ceux des utilisateurs qui consomment nos produits, afin de tirer le meilleur parti des limites biologiques de notre condition.

SOURCES

Baddeley, Adrian J.. “The magical number seven: still magic after all these years?” Psychological review 101 2 (1994): 353-6 DOI:10.1037/0033-295x.101.2.353

Can testedness be effectively measured ?

Wed, 19 Jan 2022 00:00:00 +0000

🔨 C’est dans les vieilles controverses que l’on trouve les meilleurs papiers. 5 chercheurs démontrent que le score de mutation ne fait pas mieux que le coverage pour éviter des bugs futurs. Leur résultat va à l’encontre du consensus établi. Artefact statistique ? Non, nouvelle méthode de calcul et critique rigoureuse des précédents travaux.

🐛 La méthode de calcul précédemment admise, consistait à introduire des bugs dans un programme, puis à vérifier le pourcentage de ces bugs couverts par la méthode testée (branch coverage, statement coverage, mutation score, etc.).

🪲 Pour les auteurs, il n’y a qu’une très faible corrélation avec les bugs réels. Ils ont préféré miner les sources de logiciels Open Source et vérifier, pour chaque bug résolu, si le code fautif était couvert par la méthode testée.

🏆 Le résultat renvoie le score de mutation au niveau des autres méthodes : utile pour repérer les parties sous-testées, pas plus. Le champion tombe de son piédestal.

📝 Évidemment, une étude ne changera pas le consensus, elle devra être répliquée, mais il s’agit d’une belle avancée de la recherche.

SOURCES

Ahmed, Iftekhar, Rahul Gopinath, Caius Brindescu, Alex Groce and Carlos Jensen. “Can testedness be effectively measured?” Proceedings of the 2016 24th ACM SIGSOFT International Symposium on Foundations of Software Engineering (2016): n. pag.

On the relation of refactorings and software defect prediction

Mon, 17 Jan 2022 00:00:00 +0000

🔄 Le refactoring est craint par les managers, qui pensent que les développeurs le pratiquent par pur perfectionnisme, sans preuve de son efficacité. Et pourtant, cela fait plus de 10 ans que la recherche a tranché : après un refactoring, plus de bugs sont corrigés et le temps moyen pour les résoudre diminue !

⚠️ Attention cependant aux faux-refactorings. Le refactoring modifie la structure du code, sans modifier son comportement. C’est cette technique qui a été validée par la recherche. Pas le remaniement à la fourche de larges morceaux de code. Deux moyens sont possibles :
-Refactoring assisté, où l’IDE sécurise les changements, le développeur ne touche pas au code à la main.
-Refactoring libre, sur un code piloté par les tests. Les tests garantissent que le code n’a pas été altéré dans le service rendu.

🪲 Tout autre style de remaniement n’est pas du refactoring, juste du rework. Ce dernier ne bénéficie d’aucune validation par la recherche et pourrait même engendrer plus de bugs que ceux qu’il corrige !

SOURCES :

Jacek Ratzinger, Thomas Sigmund, and Harald C. Gall. 2008. On the relation of refactorings and software defect prediction. In Proceedings of the 2008 international working conference on Mining software repositories (MSR ’08). Association for Computing Machinery, New York, NY, USA, 35–38. DOI:10.1145/1370750.1370759

Miryung Kim, Dongxiang Cai, and Sunghun Kim. 2011. An empirical investigation into the role of API-level refactorings during software evolution. In Proceedings of the 33rd International Conference on Software Engineering (ICSE ’11). Association for Computing Machinery, New York, NY, USA, 151–160. DOI:10.1145/1985793.1985815

1999. Refactoring: improving the design of existing code. Addison-Wesley Longman Publishing Co., Inc., USA.

Realizing quality improvement through test driven development

Wed, 12 Jan 2022 00:00:00 +0000

🧪 Le papier du jour est peu original : encore un étude sur TDD ! Celle-ci vient confirmer des résultats précédents, tout en démontrant que TDD réduit aussi les défauts des commits suivants, même s’ils ne sont pas réalisés avec TDD.

🐂 Les chercheurs nous avertissent toutefois : TDD cesse d’être efficace quand l’arrêt de cette démarche pousse à ne plus maintenir ou à supprimer des tests. Pour que le cercle vertueux se poursuive tout le long d’un projet, il faut de la persévérance.

⏱️ L’effort n’est pas immense : environ 15% de temps de développement en plus par rapport au même code sans tests. Entre 40% et 80% de défauts en moins selon les projets étudiés. Aucun discipline d’ingénierie ne possède de levier aussi important d’amélioration.

SOURCE

Nagappan, N., Maximilien, E.M., Bhat, T. et al. Realizing quality improvement through test driven development: results and experiences of four industrial teams. Empir Software Eng13, 289–302 (2008). DOI:10.1007/s10664-008-9062-z

Cohesion and reuse in an object-oriented system

Mon, 10 Jan 2022 00:00:00 +0000

💥Les classes les plus réutilisées dans un même système sont celles ayant le moins de cohésion. C’est la trouvaille de deux chercheurs du Colorado. Corrélation n’est pas causalité, mais ce résultat pourrait signifier :

Hypothèse 🅰️ : Qu’il existe une causalité encore à démontrer entre faible cohésion et réutilisation. Cela paraît assez peu probable.

Hypothèse 🅱️ : que les classes réutilisées partout sont souvent aussi atteintes d’une faible cohésion et inversement. Les God Classes qui polluent la plupart des codebases correspondent à ces deux définitions.

🥼 D’autres expériences seront nécessaires pour valider ou invalider ces hypothèses. Mon instinct penche vers la seconde, mais sait-on jamais.

SOURCE

James M. Bieman and Byung-Kyoo Kang. 1995. Cohesion and reuse in an object-oriented system. SIGSOFT Softw. Eng. Notes 20, SI (Aug. 1995), 259–262. DOI:10.1145/223427.211856

J. B. Rainsberger : florilège

Fri, 07 Jan 2022 00:00:00 +0000

🏅J’ai parcouru l’ensemble des articles de l’excellent J. B. Rainsberger depuis 2006. J’en ai sélectionné trois que je vous livre comme un florilège et que j’archive pour leur grande valeur.

https://blog.jbrains.ca/permalink/how-test-driven-development-works-and-more

https://blog.jbrains.ca/permalink/refactoring-where-do-i-start

https://blog.jbrains.ca/permalink/the-importance-of-aligning-authority-with-responsibility

Test-driven development with mutation testing – an experimental study

Wed, 05 Jan 2022 00:00:00 +0000

🇵🇱 TDD n’a plus rien à prouver. Une fois les développeurs formés, son usage ne présente presque que des avantages. Bien que moins connus, le mutation testing est tout aussi robuste. Deux chercheurs polonais ont monté une expérience démontrant l’efficacité de l’alliance TDD+Mutation et les synergies entre les 2 méthodes.

🕸️ Ce n’est qu’une première expérience, mais les résultats sont concluants. La mutation permet au développeur de combler les trous laissés par le développeur, pour un coût minime en temps, donc en moyens.

🧑‍🎓 Un premier papier intéressant qui mériterait d’être reproduit chez des développeurs confirmés, l’étude ne portait que sur des étudiants, qui sont un public posant de nombreux problèmes quand il est recruté pour des études sur TDD.

SOURCES

Roman, Adam & Mnich, Michał. (2021). Test-driven development with mutation testing – an experimental study. Software Quality Journal. 29. 1-38. DOI:10.1007/s11219-020-09534-x.

Influence of Human Factors in Software Quality and Productivity

Mon, 03 Jan 2022 00:00:00 +0000

🧪 Les tests automatisés sont le seule manière abordable de contrôler la qualité d’un logiciel. Le manque de sérieux des managers et des développeurs à ce sujet sont la principale source de sous-performance des équipes de développement.

🧟 Cette conclusion audacieuse nous vient de deux chercheurs qui ont analysé les facteurs humains régissant la productivité et la qualité dans une équipe de développement.

⏰ Du côté des managers, le manque de sérieux est le principal frein à la mise en place de stratégies de test solides. La plupart ont bien été sensibilisés à l’intérêt théorique des tests, mais les passent au second plan lorsqu’une deadline est en vue.

🏫 Les développeurs, eux, manquent de formation. L’école ne leur apprend pas à tester efficacement et aucun employeur n’investit dans ces compétences qui sont chères sur le marché des formations. Ils testent sans méthodes reconnues, s’épuisent à la tâche et finissent par détester les tests.

SOURCE

Sanz, Luis Fernández and Sanjay Misra. “ Influence of Human Factors in Software Quality and Productivity. ” ICCSA (2011). DOI: 10.1007/978-3-642-21934-4_22

Reputatio

Sat, 01 Jan 2022 00:00:00 +0000

Reputatio - Janvier 2022 - Paris

Conseil en stratégie IT pour une petite agence de réputation spécialiste de Wikipédia. Ont été abordés les outils permettant d'assurer leur visibilité, ainsi que la gestion des connaissances et la veille autour de leurs clients.

Subjective Evaluation of Software Evolvability Using Code Smells

Wed, 22 Dec 2021 00:00:00 +0000

🇫🇮 Les odeurs du code sont très peu connues des développeurs, bien moins que les patterns. Pour y remédier, le finlandais Mika Mäntylä propose en 2006 une classification des odeurs du code qui est passée à la postérité. Son but : simplifier pour mieux enseigner.

🗜️De 22 odeurs « classiques » chez Fowler, Mäntylä passe à 7 familles, plus faciles à retenir et à comprendre. L’auteur a résumé sa taxonomie sur GitHub : https://mmantyla.github.io/BadCodeSmellsTaxonomy

👨‍🏫 C’est un outil précieux pour les formateurs, qui n’ont pas besoin d’entrer dans le détail des odeurs du code pour enseigner la notion.

SOURCES

Mäntylä, M. V. and Lassenius, C. « Subjective Evaluation of Software Evolvability Using Code Smells: An Empirical Study ». Journal of Empirical Software Engineering, vol. 11, no. 3, 2006, pp. 395-431.

M. Fowler and K. Beck, « Bad Smells in Code, » in Refactoring: Improving the Design of Existing Code, Addison-Wesley, 2000, pp. 75-88. DOI: 10.1007/s10664-006-9002-8

Do Crosscutting Concerns Cause Defects ?

Mon, 20 Dec 2021 00:00:00 +0000

💥 Plus une fonctionnalité est éparpillée dans le code, plus elle a de chances d’être défectueuse. Cela vaut aussi pour les Crosscutting Concerns (logs, sécurité, exceptions, etc.). Plus ils sont nombreux et moins ils sont modularisés, plus le code spaghetti guette !

💣 Ce résultat, indépendant du nombre de lignes de code, a été obtenu en 2008 par plusieurs membres de l’organisation IEEE. Ils répondaient à la question « Les Crosscutting Concerns sont-ils source de défauts ? ». La réponse est bien oui, car ils sont difficiles à modulariser, difficiles à tester et sont donc très souvent implémentés avec insouciance par les développeurs, au motif que « ça n’est pas du code métier ».

⚠️ Les Crosscutting Concerns sont partout et ne doivent pas être pris à la légère. Contrairement à la croyance courante, ils sont à confier aux plus expérimentés, pas aux juniors que l’on refuse de mettre sur le code métier.

SOURCE

Marc Eaddy, Thomas Zimmermann, Kaitlin D. Sherwood, Vibhav Garg, Gail C. Murphy, Nachiappan Nagappan, and Alfred V. Aho. 2008. Do Crosscutting Concerns Cause Defects? IEEE Trans. Softw. Eng. 34, 4 (July 2008), 497–515.

Deux classifications d'intérêt général

Fri, 10 Dec 2021 00:00:00 +0000

🇳🇱 Dans la tradition aristotélicienne, on dit que le propre de l’intelligence et de mettre de l’ordre. C’est bien ce que font Arie van Deursen et Leon Moonen, deux chercheurs néerlandais. Ils nous livrent deux classifications, une sur les odeurs de test, l’autre sur les types de refactorings.

📝 Je vous les livre en l’état, les deux papiers sont courts et clairs.

🦨 Le premier liste 11 odeurs du code courantes et 6 refactorings permettant de les éliminer.

🔙 Le second classe les refactorings de Fowler en 5 groupes selon la rétrocompatibilité entre le code après et avant refactoring.

🗣️ Ces classifications s’ajoutent à notre jargon professionnel, c’est là leur principal intérêt. Un langage commun permet à une profession une plus grande efficience, par l’économie de périphrases hésitantes.

SOURCES

Deursen, Arie & Moonen, Leon & Bergh, Alex & Kok, Gerard. (2001). Refactoring Test Code. DOI:10.5555/869201

Deursen, Arie & Moonen, Leon. (2002). The Video Store Revisited – Thoughts on Refactoring and Testing.

Evaluating software degradation through entropy

Wed, 08 Dec 2021 00:00:00 +0000

🚮 L’entropie est aujourd’hui devenu un terme poli pour désigner la pourriture logicielle. Comme l’entropie thermodynamique, l’entropie du logiciel est une notion ayant une base théorique solide, négligée lors de son passage dans le langage courant. Aujourd’hui, un papier italien de 2001, offrant la première définition rigoureuse connue de ce phénomène.

🕸️ Les 4 chercheurs définissent l’entropie d’un logiciel comme la somme des couplages entre les modules. Ces couplages peuvent être directs ou indirects, structurels (dépendances de compilation) ou cognitifs (charge mentale de devoir penser à A en éditant B).

💣 Plus un code possède d’entropie, plus la portée d’une modification est grande. Nous en avons tous fait l’expérience : modifiez un détail sur un code endetté, vous obtenez des effets de bord imprévus et tout est à revoir.

🏚️ Dans la seconde partie du papier, les chercheurs apportent les premières preuves permettant d’affirmer qu’il s’agit d’une mesure pertinente pour évaluer le vieillissement d’un logiciel, donc la nécessité d’un rajeunissement par le refactoring.

SOURCE

A. Bianchi, D. Caivano, F. Lanubile and G. Visaggio, « Evaluating software degradation through entropy, » Proceedings Seventh International Software Metrics Symposium, 2001, pp. 210-219, doi: 10.1109/METRIC.2001.915530.

Des limites à l'usage des design patterns

Mon, 06 Dec 2021 00:00:00 +0000

🪄 Après l’enthousiasme des années 1990, les années 2000 furent une période d’intense remise en question des design patterns. Loin d’être la panacée ils se révélaient un boulet pour certains usages et la plupart des bénéfices que l’on en espérait étaient absents. Quoi de plus normal, dans une discipline ayant « No Silver Bullet » pour première loi.

🇳🇴 En 2004, le norvégien Marek Vokac énonce que les patterns seuls n’ont aucun pouvoir face à la complexité intrinsèque de certaines parties du code.

🇮🇹 En 2009, 3 italiens découvrent que la combinaison de certains patterns avec la présence de crosscutting concerns (logs, sécurité, cache, etc.) augmente le nombre de défauts, car ces patterns ont tendance à éparpiller la responsabilité.

➕ Aucun de ces chercheurs n’a remis en question le bénéfice net de l’usage de patterns. Tous appellent en revanche à la prudence : ils ne conviennent simplement pas à toutes les situations. Ce serait trop facile, sinon. Notre métier est immensément complexe. C’est une bonne nouvelle pour son avenir.

SOURCES

M. Vokac, « Defect frequency and design patterns: an empirical study of industrial code, » in IEEE Transactions on Software Engineering, vol. 30, no. 12, pp. 904-917, Dec. 2004, doi: 10.1109/TSE.2004.99.

Aversano, L. & Cerulo, Luigi & Di Penta, Massimiliano. (2009). Relationship between design patterns defects and crosscutting concern scattering degree: An empirical study. Software, IET. 3. 395 – 409. 10.1049/iet-sen.2008.0105.

Brooks, Frederick P. (1986). « No Silver Bullet—Essence and Accident in Software Engineering ». Proceedings of the IFIP Tenth World Computing Conference: 1069–1076.

Sustainable Software Development through Overlapping Pair Rotation

Fri, 03 Dec 2021 00:00:00 +0000

👥 Aujourd’hui, deux papiers, dont l’un est devenu un classique, qui listent les bénéfices, attendus ou plus surprenants, du pair programming. Certains sont peu connus et justifient largement les 15% de surcoût observé par rapport à une équipe classique (et non 100%, comme le pense la croyance managériale).

Le taux de défauts en production est bien plus bas.
Le pair programming coût moins cher que les code review à résultat égal.
Les solutions trouvées sont meilleures et plus simples, donc plus maintenables.
La vélocité d’une paire est plus élevée que celle d’un développeur seul.
Les développeurs se sentent mieux à leur poste.
L’apprentissage est plus rapide, même un expert apprendra au contact d’un novice (et inversement, bien entendu)

📚 Enfin, bien moins connu, le pair programming augmente la résilience de l’équipe sans nécessiter des camions entiers de documentation, très coûteuse à maintenir et empiriquement jamais à jour.

♻️ Sedano, Ralph et Péraire appellent cette propriété « Développement durable du logiciel ». En travaillant par paires a minima tournantes, les développeurs partagent la connaissance du code « naturellement » et l’ensemble de l’équipe finit par obtenir la responsabilité collective de l’ensemble du code au bout de quelques mois.

Pour obtenir cette propriété, la rotation des paires doit être fréquente ! Des paires fixes et affinitaires ne fonctionnent pas et créent des silos. A minima, les paires doivent se chevaucher, mais la meilleure technique consiste à « polliniser » le savoir en s’assurant que toutes les paires possibles ont été pratiquées sur une itération par exemple.

SOURCES

Todd Sedano, Paul Ralph, and Cécile Péraire. 2016. Sustainable Software Development through Overlapping Pair Rotation. In Proceedings of the 10th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM ’16). Association for Computing Machinery, New York, NY, USA, Article 19, 1–10. DOI: 10.1145/2961111.2962590

Alistair Cockburn and Laurie Williams. 2001. The costs and benefits of pair programming. Extreme programming examined. Addison-Wesley Longman Publishing Co., Inc., USA, 223–243. DOI: 10.5555/377517.377531

A design methodology for reliable software systems

Fri, 03 Dec 2021 00:00:00 +0000

👵 Encore un papier de Barbara Liskov. J’ai déjà parlé d’elle dans un post précédent (lien à la fin). Dans ce papier de 1972 extrêmement actuel, elle nous explique comment produire des logiciels fiables, car testés, donc testables. Le raisonnement est long, mais rémunérateur pour qui le suit jusqu’au bout.

🐛 Elle constate d’abord que le débogage intensif n’a jamais rien résolu. Il faut des tests automatisés couvrant l’ensemble des cas utiles.

🧮 Elle ajoute qu’il serait trop complexe d’obtenir des preuves formelles qu’un logiciel complexe fonctionne, à cause du nombre trop grand d’états. Des preuves informelles peuvent suffire à condition de structurer le programmes correctement, afin qu’ils soient le plus testables et prévisibles possibles.

✔️ La testabilité est donc, pour Barbara Liskov, une question de design.

✂️ L’idée de découper le programme en modules est bonne, mais insuffisante. Un découpage bancal ajoute plus de complexité qu’il n’en masque.

2️⃣ Elle donne deux règles, tirées des travaux de Dijkstra et Parnas, déjà évoqués ici :

👉 S’appuyer sur le principes des machines virtuelles de Parnas, où chaque niveau d’abstraction s’appuie sur celui immédiatement en dessous pour réaliser des oéprations plus complexes et proches du métier.

👉 Faire de la programmation structurée, sans goto donc. L’abolition du goto qui est évidente pour nous en 2021 était encore une bataille rangée en 1972.

🔪 La combinaison de ces deux règles permet une indépendance des modules par le découplage.

✨ On obtient ainsi un programme qu’il est possible de tester comme suit :

👉 Chaque module est individuellement testé par un ensemble de tests X.

👉 Chaque assemblage de modules complet est testé par un ensemble de tests Y.

➕ Grâce au design qu’elle recommande, le nombre de cas de tests nécessaires n’est pas X*Y, mais bien X+Y pour atteindre une couverture satisfaisante, ce qui est à la portée des développeurs.

SOURCE

Liskov, Barbara. “A design methodology for reliable software systems.” AFIPS ’72 (Fall, part I) (1972). DOI: 10.1145/1479992.1480018

Les standards de code spécifiques sont bénéfiques aux projets

Wed, 01 Dec 2021 00:00:00 +0000

🍟 Cathal Boogerd et Leon Moonen nous ont déjà montré que les standards de code ne sont pas efficaces pour diminuer le nombre de bugs et peuvent même l’augmenter. Une équipe de l’INRIA Lille prolonge la réflexion en montrant que les standards du code spécifiques au projet, écrits par les développeurs, sont bien plus efficaces que les règles génériques.

⚠️C’est un outil largement sous-utilisé et même inconnu. Pour la majorité des développeurs, les alertes de leur compilateur ou de leur IDE sont presque une fatalité, ils ignorent qu’il est possible sur la plupart des langages de les augmenter de règles faites maison.

SOURCES

Andre Hora, Nicolas Anquetil, Stéphane Ducasse, Simon Allier. Domain Specific Warnings: Are They Any Better?. IEEE International Conference on Software Maintenance, Sep 2012, Riva del Garda, Italy. pp.441-450. DOI: 10.1109/ICSM.2012.6405305

Boogerd, Cathal & Moonen, Leon. (2008). Assessing the Value of Coding Standards: An Empirical Study. IEEE International Conference on Software Maintenance, ICSM. 277 – 286. 10.1109/ICSM.2008.4658076.

Assessing the Value of Coding Standards: An Empirical Study

Mon, 29 Nov 2021 00:00:00 +0000

📜 Quelle équipe n’a pas défini de standards de code ? C’est un lieu commun qu’ils permettent l’harmonie dans l’équipe et la protection contre les bugs. Mais en sommes nous sûrs ? Cathal Boogerd et Leon Moonen mettent un coup de pied dans la fourmilière : ces standards n’empêcheraient pas les bugs et pourraient même en créer !

🪲 Le raisonnement est le suivant : toute modification risque statistiquement d’introduire un bug. Une modification qui n’apporte aucun bénéfice obéit aussi à cette règle, elle est donc contre-productive. Or la majorité des standards de code est inutile (60/72 parmi les règles étudiées par l’équipe) car ne correspondant à rien de plus qu’une vague coutume d’équipe.

🔎 Pour les chercheurs, toute règle qui ne naît pas d’un problème identifié cause plus de bugs qu’elle n’en résout. Ils recommandent donc la plus grande prudence lors de l’adoption de celle-ci.

La révision régulière de ces règles afin de supprimer celles qui sont obsolètes pourrait également présenter un intérêt.

SOURCE

Test-driven development as a defect-reduction practice

Fri, 26 Nov 2021 00:00:00 +0000

🏁 Il y a des quantités de papiers expérimentaux sur TDD. Ils mériteraient une synthèse, mais en attendant je vous en livre un de plus : chez IBM, une équipe expérimentée travaillant en mode Test-Last a été comparée à une équipe de novices pratiquant TDD. Les résultats sont bluffants.

🐛 40% de nouveaux bugs en moins sur le même projet pour l’équipe TDD. Un impact minimal sur la productivité. Des tests jugés plus maintenables, qualitatifs et réutilisables.

☑️ Contrairement à beaucoup d’études qui comparent assez fallacieusement TDD à l’absence de tests, celle-ci a le mérite de comparer TDD à Test-Last. L’étude ne dit pas comment les développeurs de l’équipe TDD ont été formés, ni leur niveau précédant la formation.

✔️ Sous réserve que l’investissement, que l’on sait conséquent, soit fait, TDD semble apporter des bénéfices démontrés.

SOURCE

L. Williams, E. M. Maximilien and M. Vouk, « Test-driven development as a defect-reduction practice, » 14th International Symposium on Software Reliability Engineering, 2003. ISSRE 2003., 2003, pp. 34-45, doi: 10.1109/ISSRE.2003.1251029.

Effet tiroir et science du logiciel

Wed, 24 Nov 2021 00:00:00 +0000

🕳️ Aujourd’hui trois papiers sur le même sujet : est-ce que la participation à un design pattern rend une classe plus susceptible de changer ? Aucune réponse claire ne sera donnée, mais je vais rebondir en parlant d’effet tiroir, la plaie de la recherche.

👌 Aucun de ces trois papiers n’a de résultats significatifs dans un sens ou dans l’autre. Bref, on ne sait pas et les facteurs de confusion sont sans doute trop grands pour conclure. Pourtant les chercheurs à l’origine de ces papiers ont décidé de les publier et nous devons les y encourager.

🚮 On désigne sous le nom d’effet tiroir un biais connu dans la recherche : il est plus gratifiant de publier des résultats que de publier une absence de résultats. Les papiers présentant peu ou pas de résultats ont donc plus tendance à rester au fond d’un tiroir, alors qu’ils sont nécessaires à l’avancée de la recherche.

✔️ Ils indiquent aux autres chercheurs ce qui a déjà été tenté, afin qu’ils essaient différemment de trouver la réponse.

✔️ Ils indiquent aux praticiens que sur une question donnée, rien n’est tranché et qu’il vaut mieux adopter une posture prudente.

✔️ Ils permettent aux auteurs de méta-analyses de tempérer les résultats positifs et négatifs éventuels avec la part de papiers n’ayant rien trouvé, fiabilisant largement les résultats.

🏅 L’effet tiroir est une vrai problème en recherche, surtout par le manque de chiffres pour le caractériser. Nous avons déjà les IgNobel, il manquerait un prix pour récompenser les chercheurs qui ont déployé le plus d’efforts pour ne rien trouver.

SOURCES

Aversano, L. & Canfora, Gerardo & Cerulo, Luigi & Grosso, Concettina & Di Penta, Massimiliano. (2007). An empirical study on the evolution of design patterns. 385-394. 10.1145/1287624.1287680.

Bieman, James & Straw, Greg & Wang, Huxia & Munger, P. & Alexander, Roger. (2003). Design Patterns and Change Proneness: An Examination of Five Evolving Systems.. IEEE METRICS. 40-49. 10.1109/METRIC.2003.1232454.

M. Di Penta, L. Cerulo, Y. -G. Gueheneuc and G. Antoniol, « An empirical study of the relationships between design pattern roles and class change proneness, » 2008 IEEE International Conference on Software Maintenance, 2008, pp. 217-226, doi: 10.1109/ICSM.2008.4658070.

Why Don't They Practice What We Preach ?

Mon, 22 Nov 2021 00:00:00 +0000

🦥 Pourquoi les développeurs n’adoptent pas les bonnes pratiques ? Je crois la question elle est vite répondue, parce qu’ils sont réfractaires au changement ! Justement non, et Watts Humphrey, « le père de la qualité », qui a dédié sa vie à améliorer nos pratiques, nous livre son ressenti sur la question.

🐂 Sans dédouaner ces rares professionnels butés qui ne veulent absolument pas changer de pratiques, il désigne plusieurs mécanismes qui empêchent la majorité des développeurs de s’améliorer en continu.

🏫 En haut de la liste, le système éducatif (facs et écoles) qui ne donne pas aux étudiants les bonnes clés. Les développeurs n’apprennent pas à mesurer la qualité de leur code, étant notés sur les résultats de leurs projets, non sur la qualité de leur design.

🔥Ensuite, l’entreprise, trop focalisée sur les urgence quotidiennes pour investir dans des formations longues qui cassent le rythme de production. Humphrey note qu’un développeur sous pression tend à privilégier ce qu’il sait faire au détriment des urgences. Pour la majorité peu formée, cela signifie la production en masse de code médiocre. Il faut les épaules d’un maître pour garder un cap sous pression. C’est donc un investissement payant, mais coûteux.

⏳ Enfin, la résistance au changement n’est pas négligeable. Plus un développeur a d’expérience avec une pratique donnée, fut elle mauvaise, plus le niveau de preuve nécessaire pour le convaincre de changer est grand, surtout s’il ne possède aucun exemple autour de lui. L’atteindre nécessite un accompagnement pratique, donc de le retirer de la production. C’est sans issue.

✔️ Humphrey propose 2 leviers de changement.

👉 Former dès le berceau est le plus facile. Les étudiants sont des tabula rasa qu’il suffit de former correctement. Encore faut-il vaincre les résistances au changement de leurs professeurs.

👉 Adopter une stratégie du temps long en entreprise. La qualité d’aujourd’hui est la maintenabilité, donc la rentabilité de demain. Former ses développeurs réduit le turnover et augmente la qualité du code. Hélas c’est un gros investissement qu’une entreprise déjà sous l’eau ne peut se permettre. Le recrutement d’un lead dev charismatique, au moins le temps d’insuffler les bonnes pratiques aux autres développeurs, est une option sans doute intéressante.

SOURCES

Watts S. Humphrey, Why Don’t They Practice What We Preach? 2009, Software Engineering Institute. DOI: 10.1023/A:1018997029222

When Does a Refactoring Induce Bugs ? An Empirical Study

Mon, 22 Nov 2021 00:00:00 +0000

🛠️ Contrairement à un mythe tenace, le refactoring, même automatisé par l’IDE, présente des risques d’introduire des bugs ! La seule parade est un jeu de tests de qualité.

🤌 6 chercheurs italiens ont sorti en 2012 un papier à ce sujet. Tous les refactoring ne sont pas égaux. Renommer est souvent anodin. Manipuler les hiérarchie est le plus glissant, jusqu’à 40% des actions de type Pull Up Method et Extract Subclass introduisent des bugs, contre 15% pour le refactoring en général.

✔️ On ne répétera jamais assez l’importance des tests en logiciel, il sont le filet de sécurité qui permet au développeur de remanier son travail jusqu’à le rendre satisfaisant.

SOURCE :

M. Fowler, K. Beck, J. Brant, W. Opdyke, D. Roberts, Refactoring : Improving the Design of Existing Code. Addison Wesley, 1999

G. Bavota, B. De Carluccio, A. De Lucia, M. Di Penta, R. Oliveto and O. Strollo, « When Does a Refactoring Induce Bugs? An Empirical Study, » 2012 IEEE 12th International Working Conference on Source Code Analysis and Manipulation, 2012, pp. 104-113, doi: 10.1109/SCAM.2012.20.

When and Why Your Code Starts to Smell Bad (and Whether the Smells Go Away)

Mon, 22 Nov 2021 00:00:00 +0000

🦨 En 2017, plusieurs chercheurs emmenés par Michele Tufano ont fait une découverte : les odeurs du code (code smells) ne sont pas majoritairement introduits lors du refactoring, mais bien présents dès le départ dans un code. La pression mise sur les développeurs en est la cause principale.

📙 Cela va contre l’affirmation de Fowler dans son célèbre Refactoring, qui pensait que la majorité des odeurs apparaissent lors de l’évolution du code.

🔍 Les chercheurs notent toutefois que l’analyse statique du code élimine une grande partie des odeurs. Elle devrait donc être lancée avant chaque commit.

SOURCES

Tufano, Michele et al. “When and Why Your Code Starts to Smell Bad (and Whether the Smells Go Away).” IEEE Transactions on Software Engineering 43 (2017): 1063-1088. DOI: 10.1109/TSE.2017.2653105

What is DevOps ? A Systematic Mapping Study on Definitions and Practices

Mon, 22 Nov 2021 00:00:00 +0000

Qu’est-ce qu’un DevOps et en suis-je ? C’est la question que je me posais régulièrement avant de tomber sur la revue de littérature de Jabbari, bin Ali, Petersen et Tanveer. Ils ont analysé une cinquantaine de papiers pour donner une définition précise du sujet, que je traduis ici.

« DevOps est une méthodologie de développement visant à combler le fossé entre développement et opérations, mettant l’emphase sur la communication et la collaboration, l’intégration continue, l’assurance qualité et la livraison avec déploiement automatisé utilisant un jeu de pratiques de développement »

Si cette phrase définit DevOps, alors j’en suis ! Un bon développeur sait livrer, avec ou sans DevOps.

En revanche, si pour vous DevOps est un moyen d’économiser un administrateur en chargeant le développeur de missions qui ne sont pas les siennes, ce n’est pas DevOps et je ne m’inscris pas dans cette démarche.

SOURCE :

Ramtin Jabbari, Nauman bin Ali, Kai Petersen, and Binish Tanveer. 2016. What is DevOps? A Systematic Mapping Study on Definitions and Practices. In Proceedings of the Scientific Workshop Proceedings of XP2016 (XP ’16 Workshops). Association for Computing Machinery, New York, NY, USA, Article 12, 1–11. DOI: 10.1145/2962695.2962707

Towards an Anatomy of Software Craftsmanship

Mon, 22 Nov 2021 00:00:00 +0000

🛠️ Je suis un artisan du logiciel. Mais qu’est-ce que cela signifie ? 4 chercheurs, emmenés par Anders Sundelin, ont publié en septembre dernier un papier tentant de cerner le concept. Le triptyque de Sandro Mancuso pourrait résumer leurs recherches : Professionalisme, pragmatisme, fierté.

3️⃣ Les conclusions du papier peuvent être organisées en 3 parties : les valeurs, les pratiques et les organisations.

🧭 Les valeurs sont le cœur de l’identité des développeurs qui se rattachent à cette école. La responsabilité et le professionnalisme ressortent en premier : pour les artisans eux-mêmes, faire correctement leur métier n’est pas négociable. Chaque développeur doit se sentir responsable de l’état de l’ensemble du code et en tirer une certaine fierté. L’artisan doit transparence et honnêteté à son client quant à l’état du code, via la mise en évidence de la dette technique, par exemple. C’est aussi un refus du découpage industriel des tâches dans le développement. Pour les plus radicaux, l’architecte doit disparaître au profit d’une réflexion collégiale entre équipes, mais la plupart s’accordent sur son implication forte au sein des équipes de développement « les mains dans le cambouis ».

🎛️ Les pratiques forment des règles de l’art. Elles sont composées d’un cœur de techniques anciennes et éprouvées, issues en majorité d’Extreme Programming (XP), auxquelles s’ajoutent des bonnes pratiques tenant lieu de lois du logiciel, comme les principes SOLID. On y retrouve la valorisation de la simplicité, ATDD, la méfiance envers toute documentation qui ne serait pas engendrée par du code et l’accent mis sur la livraison et le feedback.

🕸️ Les organisations procèdent des valeurs et des pratiques. On y retrouve des conférences comme Socrates, SCNA ou NewCrafts, bâties en réaction à ce qu’est devenue l’agilité, buzzword pour managers ayant ses coachs et ses certifications hors de prix, bien éloignées des préoccupations des développeurs. Les coding dojo et les katas sont un marqueur fort, tant en entreprise que dans des tiers-lieux servant de rassemblement à de véritables communautés néo-corporatives*, unies par une culture de l’apprentissage permanent. Les auteurs rejoignent les conclusions de Benjamin Tainturier et Emanuelle Duez, qui ont clairement réalisé leur enquête, à dessein ou non, auprès d’artisans.

* le terme n’est pas dans le papier.

SOURCES

Anders Sundelin, Javier Gonzalez-huerta, Krzysztof Wnuk, and Tony Gorschek. 2021. Towards an Anatomy of Software Craftsmanship. ACM Trans. Softw. Eng. Methodol. 31, 1, Article 6 (January 2022), 49 pages. DOI:10.1145/3468504

Sandro Mancuso, The Software Craftsman : Professionalism, Pragmatism, Pride. 2014. Pearson. ISBN:978-0134052502

Benjamin Tainturier, Emmanuelle Duez, The Boson Project. Décoder les développeurs. Enquête sur une profession à l’avant-garde. 2017. Eyrolles.

Towards a Mapping of Software Technical Debt onto Testware

Mon, 22 Nov 2021 00:00:00 +0000

🦨 Vous pensiez vos tests exempts d’odeurs du code ? Deux chercheurs suédois piétinent vos douces illusions.
Non seulement les tests sont du code, donc sujets à des variantes des odeurs et antipatterns qui affaiblissent les logiciels, mais ils ont en plus leurs odeurs spécifiques.

⛓️ Tout code est une responsabilité (liability). Pas seulement le code de production. Le code le plus robuste est celui qui n’existe pas, ce qui vaut aussi pour les tests. Le meilleur code est toujours celui qui offre le plus grand résultat avec le moins de lignes de codes, tests inclus.

📚 Dijkstra disait qu’un logiciel n’est utile que si la masse de documentation nécessaire à l’opérer est inférieure à la taille de ses sources. Il n’est pas aberrant de penser la même chose pour les tests.

SOURCES

E. Alégroth and J. Gonzalez-Huerta, « Towards a Mapping of Software Technical Debt onto Testware, » 2017 43rd Euromicro Conference on Software Engineering and Advanced Applications (SEAA), 2017, pp. 404-411, doi: 10.1109/SEAA.2017.65.

Edsger Dijkstra, On the Reliability of Programs

https://wiki.c2.com/?SoftwareAsLiability

The role of knowledge in software development

Mon, 22 Nov 2021 00:00:00 +0000

🧠 Comment la psychologie voit le savoir et quel est son rôle dans le développement de logiciels ? Le professeur Robillard le vulgarise avec brio dans un papier qui a plus de 20 ans, mais qui reste une merveille.

Pierre N. Robillard. 1999. The role of knowledge in software development. Commun. ACM 42, 1 (Jan. 1999), 87–92. DOI:10.1145/291469.291476

The chaos of software development

Mon, 22 Nov 2021 00:00:00 +0000

⚛️ La complexité d’un programme est-elle liée à celle de la méthode utilisée pour le développer ? Oui d’après un papier de deux chercheurs canadiens en 2003. Ils ont utilisé une application de l’entropie de Shannon afin d’évaluer la corrélation entre ces deux variables.

🔊 Plus la méthode de gestion de projet utilisée complique la tâche des développeurs, moins le code sera simple (donc maintenable) à la fin du processus. Cela peut s’expliquer de différentes manières :

❌ Le bruit, à savoir toutes les information confuses ou non-pertinentes que les développeurs doivent trier pour faire leur métier
❌ L’incertitude, qui provoque des redéveloppements évitables.

✔️ Le papier valide deux éléments des Software Wastes de Todd Sedano, qui est ultérieur.

⛏️ Comment inverser la vapeur si c’est déjà trop tard pour votre projet ? Les auteurs donnent toujours la même réponse : le refactoring. C’est un consensus souvent exprimé dans l’ensemble des papiers que j’ai pu lire, décidément.

SOURCES

Hassan, A. and Richard C. Holt. “The chaos of software development.” Sixth International Workshop on Principles of Software Evolution, 2003. Proceedings. (2003): 84-94. DOI: 10.5555/942803.943729

Sedano, Todd & Ralph, Paul & Péraire, Cécile. (2017). Software Development Waste. DOI: 10.1109/ICSE.2017.20

Technical decision-making in startups and its impact on growth and technical debt

Mon, 22 Nov 2021 00:00:00 +0000

On sait peu de choses des facteurs de réussite des startups sur le champ du logiciel, car le domaine est peu étudié. Cependant, Carl Hultberg, étudiant en management industriel nous livre une excellente synthèse du peu que nous savons.

Les généralités sont simples et intuitives : 📈 satisfaire ses utilisateurs et 📉 juguler la dette technique.

Pour cela, deux pratiques sont recommandées.

👉 Créer une équipe produit au profil technico-fonctionnel, très proche des développeurs. La plupart des méthodes agiles recommandent même un Product Owner faisant partie de l’équipe de développement.

👉Toujours ramener les features à l’essentiel. Pas de superflu, moins de code. Moins de code, moins de dette.

Ces conclusions sont à augmenter avec ce que nous savons de la dette technique, que l’auteur n’a pas la formation pour repérer : tester son code pour permettre un refactoring fréquent, seul remède efficace contre la dette.

Source : Hultberg C., Technical decision-making in startups and its impact on growth and technical debt

Rule-based Assessment of Test Quality

Mon, 22 Nov 2021 00:00:00 +0000

🇫🇷🇨🇭 Comment évaluer la qualité d’un jeu de tests ? Le coverage ne suffit pas. Les tests de mutation n’attrapent que les erreurs triviales. Dans un papier de 2007, une équipe Franco-Suisse démontre que les odeurs des tests (Test Smells) sont un outil pertinent pour repérer les mauvais tests.

🦨 Les Test Smells sont les cousins des Code Smells, qui matérialisent des problèmes de qualité potentiels dans un code. Moins connus, ils n’en ont pas moins été jugés efficaces par la recherche et ce papier l’appuie. La plupart des Test Smells sont attachés à un Antipattern de test. Ainsi les odeurs peuvent aider à découvrir qu’un test est trop long, obscur ou erratique. Les chercheurs ont ainsi identifié 27 odeurs reliés à un ou plusieurs antipatterns.

✔️ Leur recherche visait à créer un outil automatisé de détection des tests. Ce faisant ils nous livrent des conclusions intéressantes en tant que praticiens :
👉 Les Test Smells sont fréquents et nettement reliés aux antipatterns.
👉 Plus un développeur écrit de tests, meilleurs ils sont.

Leur outil mériterait d’être adapté dans nos langages, mais rien ne remplacera jamais l’oeil du praticien entraîné !

SOURCE

Reichhart, Stefan, Tudor Gîrba and Stéphane Ducasse. “Rule-based Assessment of Test Quality.” J. Object Technol. 6 (2007): 231-251. DOI:10.5381/jot.2007.6.9.a12

Recovery, redemption, and extreme programming

Mon, 22 Nov 2021 00:00:00 +0000

Extreme Programming peut (aussi) redresser des projets en perdition à condition de ne pas avoir une approche dogmatique et d’accepter des sacrifices. C’est l’essence du témoignage déjà ancien de Peter Schuh.

Le paysage a peu changé, d’après mon expérience en ESN ou en tant que freelance. Ce papier est toujours actuel.

P. Schuh, “Recovery, redemption, and extreme programming,” in IEEE Software, vol. 18, no. 6, pp. 34-41, Nov.-Dec. 2001, doi: 10.1109/52.965800.

Programming with abstract data types

Mon, 22 Nov 2021 00:00:00 +0000

👵 Tout développeur connaît les principes SOLID. Peu connaissent l’auteur du troisième : le Principe de Substitution de Barbara Liskov. Cette grande dame inventa le premier langage de programmation supportant l’abstraction. Autant dire qu’elle a pavé la voie aux langages de haut-niveau modernes.

📦 Son article de 1974 « Programming with abstract data types » est devenu un classique. Elle y détaille un paradigme de programmation, héritier de la programmation structurée de Dijkstra, dans lequel le développeur n’utilise pas directement les types fournis par le système. Ceux-ci sont encapsulés dans des types de plus haut-niveau, ne laissant filtrer que les détails pertinents du niveau précédent.

🎰 Ces types sont définis par les opérations que l’on peut réaliser sur eux (et non pas sur les données qu’ils contiennent !). Elle ne parle pas d’objet ou d’interface, concepts encore balbutiants à l’époque (Alan Kay travaille encore sur Smalltalk), mais l’idée est décidément dans l’air du temps.

3️⃣ Son paradigme présente trois énormes avantages, déjà identifiés dans le papier :
✔️ Protéger le développeur contre les erreurs d’inattention (additionner un int et un char par exemple).
✔️ Réduire la charge mentale* du développeur, qui peut se concentrer sur l’espace du problème sans se soucier des détails d’implémentation. Les types sont semblables aux oeillères des animaux de trait.
✔️ Rendre le programme plus facile à tester* : le jeu de tests* est divisé en deux parties indépendantes, l’une vérifiant l’implémentation, l’autre que l’abstraction est appelée correctement. Cette seconde partie doit ignorer tout de l’implémentation.

📝 Si la manière de concevoir des langages a vieilli (et donc la seconde partie du papier de Liskov), les principes fondamentaux sont toujours d’actualité, je ne peux qu’en conseiller la lecture.

* Ces termes n’existaient pas à l’époque

SOURCE

Liskov, Barbara and Stephen N. Zilles. “Programming with abstract data types.” SIGPLAN Notices 9 (1974): 50-59. DOI: 10.1145/800233.807045

Organizing Programs Without Classes

Mon, 22 Nov 2021 00:00:00 +0000

😱 En 1986 naît la programmation orientée prototype, célèbre grâce à JavaScript. Paradoxalement, ce paradigme est relativement inconnu, voire fui par les développeurs JS qui préfèrent oublier son existence ! Quel échec pour celui qui était vu comme révolutionnaire en 1991, au sens littéral du terme : il visait l’abolition des classes.

🤳 Aujourd’hui un papier historique de 4 chercheurs de Stanford, dont David Ungar, le créateur de Self, premier langage orienté prototype.

🗑️ Les auteurs y défendent une thèse osée : les classes sont inutiles à la programmation orientée objet, voire même gênantes. Tout ce que font les classes peut être fait plus simplement par la copie de prototypes : héritage, composition, encapsulation, polymorphisme. Mieux, les prototypes apportent l’héritage dynamique et la modification du comportement hérité par les enfants.

🕵️ L’intérêt de ce papier est surtout historique, 30 ans après, un bilan s’impose :
❌ Les classes sont bien vivantes et les pratiques actuelles tendent vers des systèmes de typage de plus en plus forts.
❌ JavaScript vit sans assumer son paradigme historique (cocasse pour quelque chose de révolutionnaire), en témoigne le succès des diverses surcouches et frameworks (NodeJS, TypeScript, etc.).
❌ L’héritage dynamique n’a pas trouvé d’usage.
❌ La modification du comportement hérité est vue comme un antipattern en Orienté Objet car il brouille la compréhension.
❌ En dehors de LUA, tous les autres langages orienté prototype sont tombés dans l’oubli.
✔️ Le principal héritage de l’orienté prototype est l’idée de traits, présents dans la plupart des langages OO de nos jours, sous diverses formes.
✔️ La notion de délégué pourrait venir de l’orienté prototype mais son origine est plus floue.

🛑 Bien qu’élégante sur le papier, l’idée des langages a prototypes a souffert de sa courbe d’apprentissage exécrable, totalement incompatible avec la cible de son principal porte-drapeau : JS, le langage des débutants par excellence. Peu sont même au courant du paradigme auquel obéit ce langage. La plupart ont adopté les codes de la programmation fonctionnelle ou impérative lorsqu’ils programment en JS.

SOURCE

Chambers, Craig & Ungar, David & Chang, Bay-Wei & Hölzle, Urs. (1991). Organizing Programs Without Classes.. Lisp and Symbolic Computation. 4. 223-242. 10.1007/BF01806107.

On the reliability of programs

Mon, 22 Nov 2021 00:00:00 +0000

Notre profession a peu de mémoire, nous avons oublié Lehman, Royce ou Wirth et de Dijkstra, il ne reste que des citations.

« Les tests peuvent être utilisés pour démontrer la présence de bugs, jamais leur absence. »

« Tout morceau de code ou programme complet n’est un outil utile que si la documentation nécessaire à l’utilisateur est plus courte que le code. »

« Notre culture a déjà pour tradition séculaire une discipline intellectuelle dont le but premier est de structurer efficacement une complexité autrement ingérable. Les Mathématiques. »

Ces trois éclairs de génie sont tous issus du même papier (en anglais), que je vous invite à lire : On The Reliability Of Programs.

SOURCE

Dijkstra E., On the Reliability of Programs (EWD303)

On the effects of programming and testing skills on external quality and productivity in a test-driven development context

Mon, 22 Nov 2021 00:00:00 +0000

👶 « TDD c’est pour les devs chevronnés, j’ai une plâtrée de juniors, je préfère oublier. »
💪 « Le seul moyen de faire de la qualité c’est d’avoir des vieux devs barbus. »
Si avec une seule étude on débunkait tout ça ?

📐L’introduction est peut-être un peu putaclic, mais d’après les résultats qu’ont obtenu 3 chercheurs finlandais, les compétences seules d’un développeur n’ont pas de lien avec la qualité des logiciels qu’il produit. J’émets l’hypothèse que le contexte et les pratiques sont le facteur principal.

❓ Un junior peut donc produire un code de meilleure qualité qu’un senior, s’il est dans un bon environnement et respecte des pratiques reconnues. Où est le piège ?

👴 L’étude montre également que les compétences sont fortement corrélées avec la productivité d’un développeur. A qualité égale, le senior est plus performant.

📈 Et TDD dans tout ça ? Les chercheurs montrent une hausse de productivité chez tous les développeurs (ce qui vient ajouter un papier à ce débat très vif qui ne sera clos que par une méta-étude solide). Cette hausse est plus importante chez les développeurs ayant déjà de la pratique.

✔️ Cela colle avec mon expérience comme enseignant, TDD est compatible avec des étudiants. Cela ne signifie pas que ce soit simple à apprendre, mais que la hausse de productivité pourrait intervenir plus tôt que l’on ne croît.

Note de fin : l’étude comporte des biais, comme tout ce que je présente. Lisez pour vous faire votre propre idée.

SOURCE

Davide Fucci, Burak Turhan, and Markku Oivo. 2015. On the effects of programming and testing skills on external quality and productivity in a test-driven development context. In Proceedings of the 19th International Conference on Evaluation and Assessment in Software Engineering (EASE ’15). Association for Computing Machinery, New York, NY, USA, Article 25, 1–6. DOI:10.1145/2745802.2745826

On the Criteria To Be Used in Decomposing Systems into Modules

Mon, 22 Nov 2021 00:00:00 +0000

🎺 « Si les développeurs chantaient des hymnes, le plus populaire serait l’hymne de la modularité » c’est ainsi que David Parnas commence son article « On the Criteria to be used in Decomposing Systems into Modules » en 1971. Un article que toute personne tentée par les microservices doit lire.

✂️ Après une démonstration, il conclut en priant les développeurs d’arrêter de découper leurs programmes à l’avance sur la base d’un organigramme. Cela ne fonctionne pas mieux en 2021 qu’en 1971. Il encourage plutôt à commencer par un monolithe, qui sera découpé au besoin lorsqu’une décision de design importante sera prise.

🔀 Cette décision sera masquée au programme principal, ce qui permet de n’avoir qu’un module à changer si cette décision s’avérait mauvaise et qu’il fallait prendre une autre voie.

SOURCE :

Parnas, David. (1972). On the Criteria To Be Used in Decomposing Systems into Modules. Communications of the ACM. 15. 1053-. 10.1145/361598.361623.

La cybernétique à l’aune des sciences cognitives : une erreur scientifique ?

Mon, 22 Nov 2021 00:00:00 +0000

🏛️ C’est devenu un lieu commun au sein des sciences cognitives, de critiquer la cybernétique, dont la discipline est pourtant issue.
Marvin Minsky, un des fondateurs de l’IA, comme Hubert Dreyfus, son vieil adversaire s’accordent sur les fruits anecdotiques de la « science des systèmes auto-organisés » et sur son absence totale de résultats.

Pourtant, peut-on parler d’erreur scientifique ?

🇫🇷 Pour Mathieu Triclot, philosophe à l’université Lyon 3, oui et son papier utilise la cybernétique pour illustrer le concept d’erreur scientifique.

❌ La cybernétique n’est pas critiquée pour ses mauvais résultats, un scientifique qui se trompe n’est pas dans l’erreur, il participe à la science ! C’est bien l’absence de résultats malgré l’entêtement des cybernéticiens qui est en cause.

❌ Seconde accusation, que les cybernéticiens en soient conscients ou non, leur discipline s’est largement éloignée de la discipline scientifique jusqu’à se mettre en porte-à-faux avec plusieurs de ses règles.

❌ Dernière accusation : A force d’analogies mal cadrés entre des disciplines dissemblables, la cybernétique a fini par ressembler à une idéologie scientifique (Canguilhem). Elle n’a produit que des visions du monde, pas des des preuves scientifiques quelconques. Le propos ressemble à celui de Sokal et Bricmont dans leur célèbre livre.

✔️ Le papier a un intérêt pour nous : ne créons pas d’autres cybernétiques en montant en épingle un sujet de recherche par la seule force de la « hype ». L’interface homme-machine, l’homme augmenté, l’IA forte, la blockchain sont des sujets à risque.

SOURCES

Mathieu Triclot. La cybernétique à l’aune des sciences cognitives : une erreur scientifique ? . Journée d’études ”qu’est-ce qu’une erreur scientifique ?”, Université Lyon 3 Jean Moulin, May 2004, Lyon, France.

Sokal A., Bricmont J., Impostures Intellectuelles, 1997, Odile Jacob, Paris ISBN 978-2-7381-0503-5

Iterative and Incremental Development: A Brief History

Mon, 22 Nov 2021 00:00:00 +0000

Je pensais avant cet article que la maturité de notre profession avait été atteinte dans les années 70. Il n’en est rien. En 1958, on savait faire de bons logiciels, avec une méthode proche d’eXtrem Programming.
Le programme Mercury en témoigne.

63 ans de perdus, on continue ou on change nos pratiques ?

SOURCE

Craig Larman and Victor R. Basili. 2003. Iterative and Incremental Development: A Brief History. Computer 36, 6 (June 2003), 47–56. DOI:10.1109/MC.2003.1204375

How soon will we learn these software engineering lessons ?

Mon, 22 Nov 2021 00:00:00 +0000

Ce papier de 1979 constate que depuis 1961, le secteur du logiciel est incapable de réussir ses produits. En cause : délais déraisonnables, violation de la loi de Brooks, empilement de spécifications, management toxique, gestion de projet monobloc. En 2021 ? Rien n’a changé.

SOURCE

Barry W. Boehm, Software Engineering - As It Is (1979)

How do fixes become bugs ?

Mon, 22 Nov 2021 00:00:00 +0000

🐞 Certains bugs ne doivent surtout pas être résolus dans la précipitation, même s’ils bloquent une fonction vitale en production. Le risque que le hotfix soit un bug encore plus gros est bien trop grand.

C’est l’alerte levée par le papier, déjà ancien (2011) de Yin et al.

3️⃣ Ces familles de bugs tiennent en 3 lettres : CMS.
-Concurrency (Locks, Tasks, Sync, etc.)
-Memory (Allocation, Overflow, Pointers, etc.)
-Semantic (Application-specific)
Respectivement 40%, 14% et 17% des patchs devant résoudre ces bugs sont eux-mêmes buggés !

🔒 Pire, sur les verrous, sujet très dangereux en développement, les chercheurs ont noté que 14% des patchs venant corriger un bug introduit par un autre patch sont eux-mêmes buggés !

🧠 Testez vos bugs, Defect Testing évite énormément de problèmes sur ces sujets où nos cerveaux sont dépassés par la complexité du code.
SOURCE :

Zuoning Yin, Ding Yuan, Yuanyuan Zhou, Shankar Pasupathy, and Lakshmi Bairavasundaram. 2011. How do fixes become bugs? In Proceedings of the 19th ACM SIGSOFT symposium and the 13th European conference on Foundations of software engineering (ESEC/FSE ’11). Association for Computing Machinery, New York, NY, USA, 26–36. DOI: 10.1145/2025113.2025121

Exploring the Influence of Identifier Names on Code Quality: An Empirical Study

Mon, 22 Nov 2021 00:00:00 +0000

Un nommage inadapté obscurcit le code, c’est entendu. Mais plus surprenant, un nommage inadapté est également un bon moyen de détecter les morceaux de code les plus buggés. Une équipe anglaise a établi une forte corrélation entre code mal fichu et nommage aux fraises.

🔙 Les chercheurs ne nous disent pas si un lien de cause à effet existe. J’émets pour ma part deux hypothèses :

🕸️ Hypothèse 1 : Dans un code mal nommé, les bugs ont plus d’endroits où se cacher.

🐖 Hypothèse 2 : Il faut chercher une cause commune en la personne du développeur incompétent. Celui qui nomme mal est aussi celui qui teste peu et laisse derrière lui beaucoup de bugs.

🧪 Si des chercheurs avancent sur le sujet, je vous ferai part des résultats !

SOURCE

Butler, Simon & Wermelinger, Michel & Yu, Yijun & Sharp, Helen. (2010). Exploring the Influence of Identifier Names on Code Quality: An Empirical Study. Proceedings of the Euromicro Conference on Software Maintenance and Reengineering, CSMR. 10.1109/CSMR.2010.27.

Effective identifier names for comprehension and memory

Mon, 22 Nov 2021 00:00:00 +0000

🔤 On ne répétera jamais assez l’importance du nommage en développement. 70% du code est constitué d’identifiants qui, s’ils sont ésotériques, grèvent la vélocité des développements. Comment ? Deux papiers nous l’expliquent.

🧠 Le premier, rédigé en 2011 par un Italien et un Américain, met en évidence l’effet négatif des odeurs lexicales sur la localisation des concepts. Ce terme désigne le processus par lequel notre cerveau tente de mapper un artefact du code avec un concept (métier ou technique qu’il connaît), afin de comprendre sa place dans la logique globale.

❌ Des odeurs comme les abréviations excessives, les termes vagues, inconsistants, mal orthographiés ou employés brouillent les capacités de localisation des concepts.

📏 Le second, rédigé en 2007 par une équipe Britannique, fait le lien entre longueur des identifiants et mémoire. Il indique que les identifiants trop longs sont aussi néfastes que ceux trop courts. Des abréviations raisonnables sont meilleures que des identifiants complets si ces derniers sont trop longs.

♀️ Un élément surprenant est la plus grande capacité des femmes à retenir des abréviations.

🔎 Ni trop court, ni trop long, mais toujours d’une clarté irréprochable semble une bonne règle pour les identifiants.

SOURCES

Abebe, Surafel Lemma, Sonia Haiduc, Paolo Tonella and Andrian Marcus. “Lexicon Bad Smells in Software.” 2009 16th Working Conference on Reverse Engineering (2009): 95-99. DOI:10.1109/WCRE.2009.26

Lawrie, D., Morrell, C., Feild, H. et al. Effective identifier names for comprehension and memory. Innovations Syst Softw Eng3, 303–318 (2007). DOI:10.1007/s11334-007-0031-2

Don't touch my code ! Examining the effects of ownership on software quality

Mon, 22 Nov 2021 00:00:00 +0000

✅ La propriété collective du code (Collective Code Ownership, CCO) est une pratique voulant que chaque développeur se sente légitime pour modifier n’importe quelle partie du projet. C’est un modèle à forte appartenance de groupe. Établir une règle ne suffit pas, il faut lever des barrières psychologiques soulignées par la recherche.

CCO a un effet bénéfique direct sur plusieurs indicateurs :

1️⃣ La résilience, ça n’est pas pour rien que CCO fait partie du Sustainable Software Development. J’en parle ici : Sustainable Software Development through Overlapping Pair Rotation

2️⃣ La simplicité du code. Quand l’équipe n’arrive plus à connaître tout le code collectivement, CCO provoque un malaise facile à ressentir par les développeurs. Il est peut-être temps de faire le tri ou de diviser le projet en morceaux.

3️⃣ La taille de l’équipe. Quand l’équipe devient trop grande, la rotation des paires est mathématiquement impossible. Tant mieux, une équipe de développement semble psychologiquement limitée à 7 personnes.

4️⃣ L’intégration. CCO intègre mieux et plus vite les nouveaux développeurs. Pas besoin de phase d’intégration longue et improductive, le développeur fait son travail dès le premier jour, guidé par un collègue.

5️⃣ Les vitres brisées. C’est un cycle vertueux. Si tout le monde se sent impliqué, personne ne laissera de problèmes non résolus « à d’autres ». La dette technique s’accumulera moins. Le produit sera de meilleure qualité. Les développeurs s’y identifieront plus et en seront fiers. Donc ils seront plus impliqués. Etc.

📅 Je termine la série demain avec la mise en place du CCO et les barrières à lever.

SOURCES

Christian Bird, Nachiappan Nagappan, Brendan Murphy, Harald Gall, and Premkumar Devanbu. 2011. Don’t touch my code! examining the effects of ownership on software quality. In Proceedings of the 19th ACM SIGSOFT symposium and the 13th European conference on Foundations of software engineering (ESEC/FSE ’11). Association for Computing Machinery, New York, NY, USA, 4–14. DOI:10.1145/2025113.2025119

Designing Software for Ease of Extension and Contraction

Mon, 22 Nov 2021 00:00:00 +0000

👴 Je continue de découvrir l’immense David Parnas, au travers d’un second article, sur la manière de concevoir des logiciels afin qu’ils soient facile à étendre et à réduire selon les impératifs client. Il date de 1979, c’est l’information la plus dingue vu l’actualité du papier.

Règles de design

📜 Parnas donne 4 règles permettant de garder une grande souplesse dans le design des logiciels :

1️⃣ Commencer par un monolithe. Créer un module à chaque décision de design importante afin d’encapsuler cette décision et de rendre facile le changement si elle s’avérait peu judicieuse.

2️⃣ Lister les éléments qui sont susceptibles de changer. S’assurer qu’ils sont absents des interfaces des modules que l’on conçoit.

3️⃣ Ne pas subdiviser son programmes en étapes d’un traitement. Privilégier la conception par « machines virtuelles », où chaque module masque la complexité de la couche inférieure en ne laissant filtrer que ce qui est utile à des tâches plus élevées.

4️⃣ Ne créer de dépendances que si elles sont utiles. Parnas entend par là que :
1) A est plus simple parce qu’il utilise B.
2) B n’est pas plus complexe si A l’utilise.
3) Il existe un programme utile incluant B, mais pas A
4) Il n’y a aucun programme utile contenant A, mais pas B.

Coûts de fonctionnement et de changement

💻 Nous connaissons tous la dynamique qui lie mémoire et CPU, de sorte que toute optimisation de l’un coûte de l’autre.
Le même type de relation existe entre coût de fonctionnement et coût du changement. Je reviens sur le papier de Parnas posté il y a une semaine, car il révèle des trésors nouveaux à chaque lecture.

📏 Un logiciel générique diffère d’un logiciel flexible. Le premier répond à plusieurs cas d’usage sans changement, alors que le second ne répond qu’à un cas d’usage mais peut être facilement adapté pour en couvrir d’autres.

👉 La généricité a un surcoût de fonctionnement (le logiciel est forcément plus gros), mais un coût de changement nul.

👉 La flexibilité a n’a aucun surcoût de fonctionnement, mais possède un coût de changement dépendant de la qualité de l’implémentation.
💰 Le choix entre généricité et flexibilité est (normalement) purement stratégique et économique. Ce qu’un logiciel gagne d’un côté il le perd de l’autre. C’est une conséquence probablement indépassable de la VIIIème loi de Lehman : dans ce complexe d’interactions homme-machine, tout est gouverné par des boucles de rétroaction.

SOURCE

Parnas, David. (1979). Designing Software for Ease of Extension and Contraction. Software Engineering, IEEE Transactions on. SE-5. 128- 138. 10.1109/TSE.1979.234169.

Coverage is not strongly correlated with test suite effectiveness

Mon, 22 Nov 2021 00:00:00 +0000

🔬Arrêtez de scruter la couverture de vos tests ! C’est une perte de temps. Laura Inozemtseva et Reid Holmes ont sorti en 2014 un papier qui l’affirme, mais confirme aussi les résultats de nombreux autres chercheurs : une faible couverture prouve que les tests sont mauvais. Une forte couverture ne prouve pas qu’ils sont bons.

🎯 On retrouve ici une situation où la Loi de Goodhart s’applique : plus vous prenez le coverage comme un objectif, plus vous vous plantez.

Comment s’assurer d’avoir de bons tests ? En remettant le coverage à sa place.
✔️ Comparer le coverage actuel et le coverage précédent avant chaque commit permet de voir si le développeur n’a pas oublié de tester son code.
✔️ Sous les 80%, le coverage indique une forte dette de tests.
❌ Au-dessus de 80% la coverage ne signifie rien d’utile et le suivre peut même coûter cher, en augmentant artificiellement la taille du jeu de tests, qu’il faudra ensuite maintenir.
❌ Les méthodes de calcul du coverage longues ou élaborées n’ont pas démontré leur utilité. Allez au plus simple, si vous utilisez correctement le coverage, ça suffira.

SOURCES

Laura Inozemtseva and Reid Holmes. 2014. Coverage is not strongly correlated with test suite effectiveness. In Proceedings of the 36th International Conference on Software Engineering (ICSE 2014). Association for Computing Machinery, New York, NY, USA, 435–445. DOI:10.1145/2568225.2568271

Concise and consistent naming

Mon, 22 Nov 2021 00:00:00 +0000

🇩🇪 Hier, j’ai parlé de nommage, sans définir comment obtenir des noms clairs. Ça tombe bien, j’ai déniché un papier de 2006 écrit par deux Allemands. Fidèles à leur tradition, ils donnent deux lignes de conduite : concision et consistance.

⚠️ Le papier est très dense, je vous en recommande la lecture, ce post ne fera que de le survoler.

⭐ La règle d’or : il doit exister une relation bijective entre les concepts manipulés et les noms utilisés. Pas de polysèmes, pas d’homonymes. Dédicace à mon vieux prof de MERISE Patrice LECUONA.

🥈 Règle n°2 : la consistence. Il faut éviter les homonymes et les synonymes, ainsi que toutes les figures de style qui font un bon poème. Lorsque l’on compose un identifiant en mêlant plusieurs concepts, ces derniers doivent exister dans le vocabulaire du projet et la relation parent-enfant doit être légitime.

🥉 Règle n°3 : la concision. Pas d’ajouts. Un identifiant doit reprendre le nom du concept qu’il contient, sans préfixes et autres rajouts dont les développeurs sont friands. Si l’identifiant désigne un type particulier d’un concept, le nom doit en être le reflet clair.

Le papier ne s’arrête pas à cela, il donne d’autres recommandations et conseils très utiles, ainsi que les ressorts psychologiques à l’oeuvre. Par souci de concision, je ne détaille pas plus et vous invite à le lire.

SOURCE

Deissenboeck, F., Pizka, M. Concise and consistent naming. Software Qual J14, 261–282 (2006). DOI: 10.1007/s11219-006-9219-1

Characterizing the Relative Significance of a Test Smell

Mon, 22 Nov 2021 00:00:00 +0000

🇧🇪 En travaillant sur un outil de détection des odeurs de test (Test Smells), 3 chercheurs belges ont produit une synthèse rigoureuse et claire de ce qu’est un bon test.

✅ Premier apport : ils ont synthétisé 9 critères depuis la littérature académique : Consistance, Nécessité, Maintenabilité, Répétabilité, Auto-validation, Isolation, Concision, Robustesse, Rapidité, Automatisation et Persistance.

✅ Second apport, ils proposent un méta-modèle décrivant la place des tests dans un système logiciel. Ce méta-modèle compte 8 concepts contraints par 9 définitions, exprimées informellement en langage naturel et formellement en notation mathématique.

🧭 C’est un excellent support de formation, mais également une lecture intéressante pour toute personne cherchant à raffiner ses tests.

SOURCE

Van Rompaey, Bart & Du Bois, Bart & Demeyer, Serge. (2006). Characterizing the Relative Significance of a Test Smell. 391-400. 10.1109/ICSM.2006.18.

Analyses of Regular Expression Usage in Software Development

Mon, 22 Nov 2021 00:00:00 +0000

Les expressions régulières (Regex) sont massivement utilisées, mais très peu testées car difficilement testables, donc d’une fiabilité douteuse.

Cette conclusion est celle de la thèse (2021) de Peipei Wang, une doctorante en informatique de Caroline du Nord.

Je conseille aux non-chercheurs la lecture des chapitres 1, 3, 4, 5.

Vous y apprendrez que :
-Dans la réalité, personne ne teste ces $*x% de regex (17% sur les projets open-source étudiés).
-Elles sont une importante source de bugs vicieux.
-Elles sont encore imparfaitement portables à travers les langages.
-Les outils pour correctement les tester sont encore peu diffusés (Rex pour ne citer que lui). Elles sont encore trop testées simplement par branch coverage ou statement coverage, ce qui est erroné.
-Les développeurs en ont peur et y touchent très rarement dans leur code. Lorsqu’ils y sont contraints (bug ou évolution), ile préfèrent les supprimer et les remplacer par un parser (ce qui n’est pas toujours une mauvaise solution d’ailleurs).

https://repository.lib.ncsu.edu/handle/1840.20/39015

Adoption challenges of CI/CD methodology in software development teams

Mon, 22 Nov 2021 00:00:00 +0000

🔃L’intégration et le déploiement continus (CI/CD) ont du mal à entrer efficacement dans les pratiques des entreprises. Un professeur Sri Lankais analyse pourquoi et donne des pistes d’amélioration.

👉 En premier, l’équipe. Elle doit maîtriser un ensemble de pratiques comme les tests automatisés ou DevOps. Elle doit communiquer correctement et être capable de livrer régulièrement. Ce n’est souvent pas le cas, surtout si l’équipe est sous pression.

👉En second, de peu, le soutien des parties-prenantes. Un pipeline de CI/CD n’a aucun impact sur la productivité à court-terme et peut même ralentir les développements. C’est donc un investissement, qui doit être compris et accepté comme tel par tout le monde.

👉Sur la dernière marche du podium, le poids de l’existant. Un existant intestable ou compliqué à build changera le parcours d’adoption des outils de CI/CD en véritable enfer.

❗ Le premier comme le troisième point sont très dépendants du second. Si les parties prenantes acceptent d’investir sérieusement dans un démarche de CI/CD, alors elles mettront les moyens pour désendetter le code et former les équipes.

La balle n’est pas dans le camp des développeurs, même avec la meilleure volonté du monde.

SOURCE

Rajasinghe, Maneka (2021): Adoption challenges of CI/CD methodology in software development teams. TechRxiv. Preprint. DOI:10.36227/techrxiv.16681957.v1

A New Family of Software Anti-Patterns: Linguistic Anti-Patterns

Mon, 22 Nov 2021 00:00:00 +0000

👅Le code n’est pas écrit pour les machines, qui se contentent de signaux électriques, mais pour les humains ! Il est donc normal de retrouver des antipatterns linguistiques et autres dettes de langage dans un code.

4 chercheurs ont tenté de classifier les antipatterns linguistiques dans le code. Ils ont trouvé 6 familles, 3 pour les attributs, 3 pour les méthodes.
1) Les méthodes qui font plus qu’elles ne disent (effets de bord).
2) Les méthodes qui disent plus qu’elles ne font.
3) Les méthodes qui font l’opposé de ce qu’elles disent.
4) Les attributs dont le nom promet plus qu’ils ne contiennent
5) Les attributs qui contiennent plus que ce que promet leur nom
6) Les attributs qui contiennent l’opposé de ce qu’indique leur nom

Ces familles contiennent des antipatterns, comme ces Get impurs qui sont bien plus que des accesseurs, ces ‘IsX’ qui renvoient autre chose qu’un booléen, ces commentaires qui contredisent ce qu’ils illustrent ou encore ces méthodes de transformation qui ne retournent rien.

Bien entendu leur travail n’est qu’un premier pas, il existe de nombreux autres antipatterns, sur les noms des classes par exemple. Mais il a le mérite de lancer le sujet, inexploré avant eux.

SOURCE

Arnaoudova, Venera & Di Penta, Massimiliano & Antoniol, Giuliano & Guéhéneuc, Yann-Gaël. (2013). A New Family of Software Anti-Patterns: Linguistic Anti-Patterns. Proceedings of the European Conference on Software Maintenance and Reengineering, CSMR. 10.1109/CSMR.2013.28.

A Brief History of Software Engineering

Mon, 22 Nov 2021 00:00:00 +0000

👴 Mes lectures de la semaine ont été bien plus historiques et sapientiales que scientifiques. Aujourd’hui, un brève histoire du logiciel de Niklaus Wirth.

🧪 Dans ce papier désabusé et volontiers sarcastique, l’auteur retrace son expérience du développement depuis les années 60. C’est décapant, mais non moins juste.

N. Wirth, “A Brief History of Software Engineering,” in IEEE Annals of the History of Computing, vol. 30, no. 3, pp. 32-39, July-Sept. 2008, doi: 10.1109/MAHC.2008.33.

Factors Limiting Industrial Adoption of Test Driven Development: A Systematic Review

Fri, 19 Nov 2021 00:00:00 +0000

🇸🇪 TDD est bénéfique pour la qualité, j’en ai déjà parlé ici. Quels sont donc les facteurs qui limitent son adoption en entreprise ? Il y en a 7 selon 3 chercheurs suédois.

🐌 Sa lenteur en temps de développement initial. A nuancer, car TDD est plus rapide si l’on prend en compte le temps de maintenance dans le calcul.

🧠 Le manque de connaissances sur TDD, renforcé par sa contre-productivité entre les mains de novices.

📐 La légende voulant que TDD ne permette pas de design. Elle n’a jamais été étayée par la recherche ou par l’expérience des praticiens, pourtant elle reste ancrée dans la tête des managers.

🗜️ Le manque de compétences en tests. En effet, TDD requiert des développeurs qui savent déjà (bien) tester. Ce n’est pas souvent le cas en entreprise. La bonne nouvelle, c’est que l’on peut apprendre directement avec TDD.

🧲 De mauvaises implémentations de TDD, alors que l’on sait que TDD doit être correctement appliqué pour présenter des bénéfices clairs.
❌ Des limitations propres au domaine ou aux outils. Il est par exemple très difficile de tester des GUI en TDD.

🗑️ La présence de Code Legacy, que TDD ne sait pas traiter (il faut d’autres techniques pour ça).

💩 En conclusion : apprendre TDD n’améliore pas les performances à court terme et peut même les gréver. Il n’est pas possible de faire du « demi-TDD » sans en perdre tout l’intérêt. TDD est un investissement lourd qui ne paie qu’à long terme. Soit, selon Niklaus Wirth, l’inverse de la tendance de l’industrie depuis les années 70.

👉 Sans courage managérial, il ne faut attendre aucun bénéfice de TDD.

SOURCE

Causevic, Adnan & Sundmark, Daniel & Punnekkat, Sasikumar. (2011). Factors Limiting Industrial Adoption of Test Driven Development: A Systematic Review. Proceedings – 4th IEEE International Conference on Software Testing, Verification, and Validation, ICST 2011. 337-346. 10.1109/ICST.2011.19.

TDD est facile à enseigner

Mon, 15 Nov 2021 00:00:00 +0000

🎓 Enseigner TDD au étudiants dès le premier cours sur les tests donne des résultats encourageants ! C’est même moins difficile que de l’enseigner à des développeurs habitués à une démarche Test-Last.

🇺🇸 L’étude vient des U.S.A et compare deux groupes d’étudiants, l’un suivant la logique TDD, l’autre une démarche Test-Last plus classique. Ces étudiants n’ont jamais testé avant et ont été formés à cela en début d’expérience.

👻 Les chercheurs montrent que chez des novices, pratiquer TDD lève les peurs au sujet de cette méthode. L’apprentissage n’est pas plus difficile que celui d’une démarche Test-Last et les étudiants sont plus productifs. Aucun changement concernant la qualité du code n’est perceptible.

🍼 Cela rejoint mon expérience en formation : il est plus difficile de former à la mentalité TDD des développeurs pratiquant en Test-Last que des cerveaux vierges. L’apprentissage de TDD étant la principale barrière empêchant la pratique de se répandre, former « dès le berceau » semble présenter des avantages nets.

SOURCES

D. S. Janzen and H. Saiedian, « On the Influence of Test-Driven Development on Software Design, » 19th Conference on Software Engineering Education & Training (CSEET’06), 2006, pp. 141-148, doi: 10.1109/CSEET.2006.25.

Comme moi, obtenez GRATUITEMENT la certification ZeroCert™

Tue, 09 Nov 2021 00:00:00 +0000

Après des mois d’effort et d’opiniâtreté, notre Atelier est certifié ZeroCert™. C’est une véritable étape dans notre développement et nous tenons à auto-congratuler notre coach et notre organisme de certification à cette occasion. Cela faisait des mois que nous préparions ce titre, après y avoir longuement réfléchi, fait des matrices SWOT, des diagrammes en tous genres et même programmé un système d’aide à la décision sur le modèle de Rube-Goldberg.

ZeroCert™ est l’assurance pour nos clients qu’il n’y aura rien entre nous et leur besoin. Pas de certification à rentabiliser, pas d’attrape-nigaud A.G.I.L.E, pas technologies trop mal documentées pour être mise en œuvre sans certification cache-misère. Nada. Que des choses reprenables, simples et faciles à apprendre. Oserais-je dire bêtes ?

Nous avons fait le choix de l’artisanat. Ce choix implique des principes et des données. D’eux nous tirons un rejet total de toute forme de certification, présente, passée et future. La suite de cet article est un argumentaire.

L’auto-éducation au Cargo Cult

Cargo Cult.

Nos clients ne sont pas Amazon, Google ou Microsoft, mais la PME de Monsieur tout-le-monde. Ils n’ont pas les problématiques de scalabilité, maintenabilité et performances des GAFAM susmentionnés. Ils n’ont pas besoin de l’outillage et des stacks techniques qui vont avec. Encore moins des geeks patentés qui viendraient les leur vanter. Comme toute technologie, les Kubernetes, Kafka et autres Hadoop son nés dans des contexte particuliers, ont été optimisés pour ceux-ci et sont donc rarement des choix judicieux avant de rencontrer les problématiques auxquels ils répondent.

Adopter un outil « parce que X fait comme cela » se nomme le Cargo Cult. Les certifications en sont une forme bien plus pernicieuse et raffinée. Elles changent le professionnel certifié en VRP d’un produit qu’il n’a aucun intérêt à défendre, sauf la mise de départ qu’il a investie. A moins que vous ne soyez une très grosse entreprise, Microsoft, Oracle ou Amazon ne vous ont jamais démarché. Vos développeurs l’ont fait pour eux, et ils ont payé cher pour en avoir l’honneur.

Certaines technologies, Azure par exemple, ont une documentation exécrable, tout juste suffisante pour les usages de base. Pour aller plus loin, il faut trouver un formateur. Le formateur vit de sa certification, qu’il a souvent payée à prix d’or et qu’il doit rentabiliser. Pas besoin d’un doctorat en économie pour comprendre que l’entreprise émettrice a intérêt à produire une documentation incomplète et un produit peu intuitif. Le marché des certifications vient remplacer le défunt marché des licences, so années-2000.

La bonne odeur d’adolescence et de piratage.

Il n’y a même pas besoin de produit pour créer une certification. Il suffit d’inventer une méthode de gestion de projets, qui fonctionne selon un principe de cercle vicieux. Prenez un développeur, managé selon la méthode A.G.I.L.E fictive « CRAMPS ». Cette méthode n’a aucune base scientifique, tout au plus quelques appuis sur des pseudo-sciences comme Meyer-Briggs ou des effets de mode. Elle a peu de chances d’être efficace, surtout si elle n’est qu’un vernis sur de bonnes vielles pratiques Waterfall. Ce développeur sera malheureux en poste et rêvera de devenir chef de projet. Il dépensera donc son compte formation pour se former à la méthode CRAMPS, ou à une autre, plus en vogue et toujours aussi rigoureuse. Il appliquera cette méthode avec un zèle d’ordinand aux développeurs placés sous sa responsabilité. Un quart par bais d’aversion aux pertes, un quart pour rentabiliser sa formation, un quart par égo, un quart par confort, le reste parce qu’il y croit. Une fois expérimenté et devenu « senior », il pourra récupérer sa mise de départ par le coaching et quitter le jeu. Les plus néfastes créent leur propre méthode et « donnent » des talks. C’est un jeu à somme négative perpétué par inertie et une variante du Théorème du Singe. Sauf peut-être pour les organismes de formation.

Une entrave au marché

Tout ce qui est rare est cher.

Une technologie à certification ne s’adopte pas. Elle se refile, comme la covid ou une bonne grippe. Tous ceux qui n’en veulent pas fuient vos offres d’emploi. Au mieux, le radeau de votre certification coule de vieux jours, dans un marché vaste où vous ne peinez pas à recruter. Souvent, le marché se rétracte brusquement, parce que la mode est passée et le prix de la main d’œuvre flambe. Vous avez sur les bras un outil mal adapté à votre besoin, documenté spécifiquement pour rester l’alchimie exclusive de quelques initiés. Ces derniers arcanistes en sont conscients et vous le feront payer très cher. Ce problème existe déjà avec les langages de programmation, nul besoin d’ajouter à leur obsolescence celle de nos outils. Et nul besoin d’ajouter du risque à la pratique déjà funambulaire du développement.

Un développeur expérimenté peut apprendre très rapidement un nouveau langage ou une technique simple. Notre métier c’est l’adaptation : mettre des outils simples au service de besoins les plus complexes. Hélas, contre les barrières intentionnelles à la compréhension, nous ne pouvons rien. Et les rares à s’y risquer vous le feront comprendre sur la facture.

Conclusion : faut-il jeter les certifications ?

Vous l’aurez deviné, ce post est une réaction allergique au contenu de mon fil LinkedIn. Sur notre Facebook-like préféré, entre les auto-congratulations de startuppeurs et deux ou trois billets prétentieux sur les best-practices ou le lifestyle aux airs de publicité, nous trouvons les annonces que un·e·tel·le a obtenu sa certification « Agile Super-Saiyan Fusion 4 ».

C’est le dévoiement des certifications qui provoque chez moi de tels états cynorrhodoïdes. Car oui, elles ont leur utilité. Prenez un opérateur sur une centrale nucléaire, votre chirugien, le conducteur du TGV ou votre électricien. Même le plus hardcore des libertariens ne s’opposera pas à une certaine dose de règlementation dans ces professions. Des débats politiques interminables n’ont pas fini de définir qui doit en être l’émetteur, mais là n’est pas la question.

Il en est de même pour les certifications dans le domaine de l’IT, au sens large. Tout est question de balance entre les bénéfices des certifications, qui permettent de s’assurer qu’une personne compétente est aux manettes et les inconvénients, que nous venons de voir. L’absence de titre pour le développeur du site de e-commerce d’une boutique de gâteaux n’est sans doute pas un problème. Pour l’administrateur d’une infrastructure d’authentification bancaire, c’est sans doute nécessaire qu’il y ait contrôle (et obligation de formation continue).

Dans notre histoire, nous avons tendance à alterner des phases de surrèglementation, l’Ancien Régime crépusculaire étant un exemple, et des phases de surlibéralisation, à l’image du début du XIXème. Je suis bien trop réaliste pour espérer changer la nature cyclique du phénomène. Tout juste, j’espère en diminuer l’amplitude au sein de notre profession. Cet article n’a pas d’autre prétention.

Two Meta-Analysises

Mon, 08 Nov 2021 00:00:00 +0000

🔍 Les Méta-Analyses, plus haut niveau de preuves en science, sont assez rares en qualité logicielle. J’en ai une sur l’efficacité de TDD et l’autre sur le Pair Programming. Analysons-les ensemble.

⚠️ Ces deux analyses se rejoignent sur l’absence de standardisation des concepts étudiés et de la manière de les étudier, ce qui rend compliquée l’isolation des variables. Il est donc compliqué de conclure, sauf à avoir de très nombreuses études source.

❓ Rappel : « non concluant », « ne prouve rien » et autres formules de ce style signifient que rien ne peut être conclu. Ni l’efficacité, ni l’inefficacité.

🤝 Sur Pair Programming, des conclusions surprenantes : il est plus rapide d’être deux sur des tâches simples, mais la qualité va baisser. Sur des tâches complexes, être deux produira un meilleur code, au prix d’une baisse de productivité.
C’est contre-intuitif autant pour les partisans que pour les détracteurs de pair-programming. Cela signifierait que si la qualité compte, il est mieux de laisser les développeurs seuls sur les tâches simples. Si c’est la productivité qui compte, il faut pairer sur les plus triviales !

☑️ Sur TDD, il a un effet positif sur la qualité d’autant plus grand que la tâche est grande, en revanche, il n’a aucun résultat concluant sur la productivité. Ce résultat est plus appuyé dans l’industrie (probablement car les développeurs ont plus de bouteille qu’à l’université) et quand d’autres pratiques d’XP sont utilisées avec TDD.

🕰️ Sur ces deux sujets, les chercheurs déplorent l’absence de papiers sur les effets long-terme de ces deux techniques.

SOURCES
Y. Rafique and V. B. Mišić, « The Effects of Test-Driven Development on External Quality and Productivity: A Meta-Analysis, » in IEEE Transactions on Software Engineering, vol. 39, no. 6, pp. 835-856, June 2013, doi: 10.1109/TSE.2012.28.

Jo E. Hannay, Tore Dybå, Erik Arisholm, Dag I.K. Sjøberg, The effectiveness of pair programming: A meta-analysis, Information and Software Technology, Volume 51, Issue 7, 2009, Pages 1110-1122, ISSN 0950-5849, DOI:10.1016/j.infsof.2009.02.001

Are mutants a valid substitute for real faults in software testing

Fri, 05 Nov 2021 00:00:00 +0000

👾 Les indicateurs classiques de couverture du code ne sont pas corrélés à l’efficacité des tests*. En revanche, le score de mutation l’est significativement, pour un effort de tests moindre. Pourtant, malgré des outils efficaces, la mutation n’est pas une pratique courante en développement.

🔧 Ils se nomment Stryker en .NET, PIT ou Jumble en Java, mais tous les grands langages possèdent un outil de mutation simple d’utilisation. Les CPU modernes ainsi que les langages intermédiaires (MS IL, Bytecode) rendent ces outils suffisamment rapides pour les faire tourner avant chaque commit en mode partiel, et à chaque intégration en mode complet. Pourtant ils demeurent largement méconnus des développeurs.

🪄 Il ne s’agit pas d’une technique parfaite (No Silver Bullet, rappelez-vous). Ils ne détectent que les bugs issus du code, pas les problèmes d’algorithmique et les effets de bord complexes, mais c’est déjà énorme vu le très faible investissement qu’ils représentent.

💻 Intégrés dans un IDE ou dans une plateforme de CI, ils dévoilent tout leur potentiel et sont le complément parfait de TDD. Essayez, vous serez rapidement conquis !

* Voir le post d’il y a 6 jours : Coverage is not strongly correlated with test suite effectiveness

SOURCES

N. Li, U. Praphamontripong and J. Offutt, « An Experimental Comparison of Four Unit Test Criteria: Mutation, Edge-Pair, All-Uses and Prime Path Coverage, » 2009 International Conference on Software Testing, Verification, and Validation Workshops, 2009, pp. 220-229, doi: 10.1109/ICSTW.2009.30.

A quoi servent les juniors ?

Mon, 25 Oct 2021 00:00:00 +0000

Notre profession gâche le potentiel de ses juniors. Vendus comme des ressources clé en main en sortie d’école, ils sont une main d’œuvre peu onéreuse et très malléable pour les employeurs, ESN en tête. A travers le mythe tenace du mois/homme, on exige d’eux la même productivité qu’un senior sur les mêmes tâches. Ce n’est ni rendre service aux juniors, ni rendre service à l’entreprise. A quoi servent donc les juniors ? Ce papier aux airs de plaidoirie en faveur de mes (anciens) étudiants tente d’y répondre.

Cet article est la suite de mon propos stratégique paru en juin 2020. Il peut cependant être lu indépendamment.

Est un junior tout professionnel qui, par manque d’expérience donc d’assurance, est incapable d’identifier ou de refuser les situations où les règles de l’art sont violées.

C’est une définition très large, incluant autant les développeurs inexpérimentés que les Expert Beginners, trouvant normales des situations invraisemblables parce qu’ils ont toujours travaillé ainsi. Elle est librement inspirée de la situation des apprentis en France sous l’Ancien Régime. Le jeune apprenti ne passait compagnon que lorsqu’il démontrait sa capacité à ne pas être un danger pour lui ou pour la profession. Il était cantonné aux menus travaux et aux projets d’entraînement tant que le maître ne le jugeait pas digne.

La situation est exactement la même avec les développeurs junior : ils n’ont pas l’expérience nécessaire pour être conscients du danger de mal faire. Là où leur situation est plus enviable que leurs collègues travaillant dans le monde des objets physiques, c’est la facilité d’édition, donc de rectification qu’offre le code. L’apprenti développeur peut donc être attelé à des tâches de production et cela ne pose aucun problème, tant que l’on se rappelle qu’il n’est qu’un junior jusqu’à preuve du contraire.

Une profession d’enfants

Hélas, de nombreuses entreprises, le plus souvent par ignorance, traitent les junior comme s’ils n’en étaient pas. Le junior est souvent un bon programmeur, mais un développeur en devenir. A court-terme, ses résultats font illusion. Ce n’est qu’à moyen terme, sur des paramètres de qualité comme la maintenabilité, la reprenabilité et la complexité accidentelle du code, que le junior fera défaut.

Dans toute autre industrie, le manager bien informé aurait remarqué le problème de qualité et remonté à sa source, fut-elle le travail tombé dans l’oubli d’un travailleur trop vert à l’époque. Pas dans le développement, car l’attente d’un manager envers les développeurs n’est pas la qualité, devenue un Dahu, plus souvent mentionné que rencontré, mais simplement de garder la tête hors de l’eau une itération de plus. Le développeur a remplacé le garagiste dans l’imagerie populaire.

Pire, les développeurs sont souvent aussi résignés que leurs responsables. La plupart n’ont jamais vu un projet qualitatif, n’ont même jamais entendu parler d’un développeur heureux au travail. Trop se sont résignés au tripalium, à la médiocrité subie, en attendant de « passer chef de projet » ou de fuir la profession.

Notre profession a 70 ans, dont 30 d’explosion. Cela ne se retrouve pas dans sa démographie.

Nous sommes une profession d’enfants, dont l’irresponsabilité n’est pas une accusation mais une circonstance atténuante. S’il devait y avoir un banc des accusés, les junior seraient bien les seuls à ne pas y figurer, nous sommes collectivement coupables de ce gâchis.

Les maîtres restent dans leur tour d’ivoire, ne voulant plus enseigner en école pour le prix qu’on leur propose, réservant leurs services pour quelques entreprises « qui ont déjà compris ».
Les écoles font avec les intervenants qu’elles trouvent au prix de marché, largement déterminé par l’argent que les entreprises sont prêtes à mettre dans la formation de leurs alternants.
Les entreprises n’y comprennent souvent rien et se disent, à raison, qu’il vaut mieux aller au moins cher et prendre des junior que l’on pourra modeler à son image et trier facilement, alors qu’une embauche de « Senior » reviendra dans la plupart des cas à embaucher un Expert Beginner aussi compétent qu’un junior, mais au double du prix.

Nous sommes coincés dans un cercle vicieux d’incompétence et d’irresponsabilité systémique, qu’aucun facteur seul ne résoudra. Et les seuls capables d’agir sont les développeurs conscients du problème.

De la charité envers les junior

Je ne me considère pas comme un maître. Je ne pense pas avoir atteint le niveau pour prétendre au titre. Cependant, je ne me considère plus comme un junior depuis plusieurs années. J’en suis sorti presque au hasard. Quelqu’un m’a montré la voie et je me suis débrouillé. Tout le monde n’a pas eu cette chance et les pertes sont immenses. Un vol de passereaux sur un tarmac d’aéroport.

Créer une culture de la qualité logicielle sera long. J’ai promis une suite à mon article de 2020 à ce sujet, la voici. Les maîtres doivent sortir de leurs tours d’ivoire. Travailler dans un atelier logiciel, entouré d’autres maîtres est une retraite nécessaire, car je ne sais que trop bien à quel point la prise en charge de débutants est un travail éreintant. Cependant trop de maîtres sont totalement coupés des juniors. Il n’y a pas de pont, même pas cette étincelle qui suffirait à quelques-uns pour démarrer un cheminement personnel hasardeux vers la qualité.

Tar Valon, dans The Wheel of Time de Robert Jordan. Une allégorie intéressante de la tour d’ivoire.

A quoi servent les juniors ? A rendre ce que nous avons reçu, bien évidemment. Nous avons souvent emprunté la voie de la qualité au hasard d’une rencontre. C’est largement inefficace mais c’est ainsi. Ce n’est pas demain que nous créerons les conditions d’une massification de la qualité (et ce sera le sujet d’un article ultérieur, dans quelques ~~mois~~ années). Le pragmatisme nous ordonne de continuer à transmettre ainsi faute de mieux. A cette fin j’identifie trois leviers, qui constituent la stratégie d’entrisme décrite dans l’article précédemment cité.

Enseigner en école. Même si c’est souvent bien plus mal payé que les formations en entreprise. C’est un acte militant qui paie. La formation continue est une pêche à la ligne, là où le travail en école est une pêche au filet. Beaucoup d’étudiants entendent, peu écoutent, mais c’est déjà plus de monde que les seuls professionnels « qui ont compris ».
Laisser une chance à ses prospects. Un client aux pratiques bancales, mais désireux d’apprendre de ses erreurs, est une opportunité sur tous les plans. Au plan humain, comme au plan économique. C’est une relation gagnant-gagnant, d’autant plus si cela permet de redonner le moral à une équipe déprimée. Pour cela la recherche académique est un outil remarquable. Ce ne sont pas les conseils d’un seul expert, c’est l’état de l’art !
Accompagner les créateurs d’entreprise. C’est auprès des futurs CEO qu’il est possible d’injecter la qualité logicielle dans les cultures d’entreprise de demain. C’est hélas aussi le travail le moins rémunérateur, le futur CEO ayant rarement les moyens de payer un expert. Les plus habiles verront cette démarche comme un investissement. Formez les décideurs dès l’incubateur, ils feront probablement appel à vous après leur levée de fonds.

Ce n’est pas parce qu’un objectif requiert la mise en branle d’un édifice stratégique à long terme qu’il est impossible d’agir sur le court-terme. Les juniors sont un formidable levier. Il faudra environ 5 ans pour qu’un junior formé et motivé transmette à son tour. C’est court, donc contagieux, la crise du Covid montre le potentiel de tels phénomènes.

Cet article possède une suite, traitant des maîtres.

Une revue sur les odeurs du code

Fri, 22 Oct 2021 00:00:00 +0000

🦨 Odeur du code ! Antipattern ! Si le capitaine Haddock était développeur, il abuserait sans doute d’un tel vocabulaire. Mais qu’en est-il de la recherche ? Ces notions sont-elles pertinentes, ou juste des caprices de développeurs ?

📝 J’ai récupéré 5 papiers, écrits entre 2009 et 2013, qui en parlent. Pour être d’accord sur la définition, une odeur du code est une indication d’un potentiel problème plus profond, l’antipattern. Fowler, qui a inventé le terme, différencie bien les deux. L’antipattern est une mauvaise solution clairement identifiée. L’odeur est un indice, ne menant pas toujours à un antipattern. Et tous les antipatterns ne « sentent » pas, certains ne sont visibles que via une analyse poussée.

🐛 Dans la littérature, les classes porteuses d’odeurs sont en général plus défectueuses et moins compréhensibles que les autres.
Cependant, les études se contredisent sur leur résistance et leur exposition au changement, qui s’explique au moins partiellement par leur plus grande taille, une variable mieux corrélée que le nombre d’odeurs à ces indicateurs.

💣 Les antipatterns sont moins étudiés, mais semblent corrélés à un plus grand nombre d’erreurs et une plus grande exposition au changement. En d’autres termes, ils changent plus souvent et leurs changements sont plus véreux que la moyenne.

🔄 La recherche montre également que toutes les odeurs ne se valent pas, certaines sont faiblement corrélées à des antipatterns, d’autres très fortement.

✔️ En résumé, les code smells indiquent bien quelque chose sur la qualité du code, mais ils ne peuvent pas se passer d’une analyse des développeurs ! Fowler a vu juste, comme souvent.

SOURCES

D. I. K. Sjøberg, A. Yamashita, B. C. D. Anda, A. Mockus and T. Dybå, “Quantifying the Effect of Code Smells on Maintenance Effort,” in IEEE Transactions on Software Engineering, vol. 39, no. 8, pp. 1144-1156, Aug. 2013, doi: 10.1109/TSE.2012.89.

Steffen M. Olbrich, Daniela S. Cruzes, and Dag I. K. Sjoberg. 2010. Are all code smells harmful? A study of God Classes and Brain Classes in the evolution of three open source systems. In Proceedings of the 2010 IEEE International Conference on Software Maintenance. DOI:10.1109/ICSM.2010.5609564

Bavota, Gabriele & Qusef, Abdallah & Oliveto, Rocco & Lucia, Andrea & Binkley, David. (2012). An empirical analysis of the distribution of unit test smells and their impact on software maintenance. IEEE International Conference on Software Maintenance, ICSM. 56-65. 10.1109/ICSM.2012.6405253

F. Khomh, M. Di Penta and Y. Gueheneuc, « An Exploratory Study of the Impact of Code Smells on Software Change-proneness, » 2009 16th Working Conference on Reverse Engineering, 2009, pp. 75-84, doi: 10.1109/WCRE.2009.28.

Li, Wei and Raed Shatnawi. “An empirical study of the bad smells and class error probability in the post-release object-oriented system evolution.” J. Syst. Softw. 80 (2007): 1120-1128. DOI:10.1016/j.jss.2006.10.018

Localisation des concepts et langage métier

Fri, 22 Oct 2021 00:00:00 +0000

🧠 Connaissez-vous le principe de localisation des concepts (Concept Location) ? Il s’agit d’une notion à la frontière de la psychologie et de l’informatique, qui désigne l’acte de retrouver le code implémentant un concept donné dans un programme. Une localisation efficace augmente grandement la productivité des développeurs.

🗣️ La principale difficulté est l’écart entre le langage naturel utilisé pour exprimer le concept et la terminologie utilisée dans le code. Plus le code est rédigé dans un langage proche du métier, plus la localisation des concepts est aisée.

👓 La connaissance du code par le développeur facilite évidemment la localisation, plus la compréhension du code par les développeurs est étendue, plus la localisation est rapide.

🧪 Enfin, des tests placés au bon niveau d’abstraction aident évidemment à repérer les concepts facilement.

🔥 Je ne peux que recommander le combo DDD+ATDD+Architecture criante pour maximiser la productivité sur des projets où le nombre de concepts est important.

SOURCES

Evans E., Domain-Driven Design: Tackling Complexity in the Heart of Software, Addison-Wesley, ISBN: 0-321-12521-5

Marcus, Andrian & Sergeyev, A. & Rajlich, Vaclav & Maletic, J.I.. (2004). An information retrieval approach to concept location in source code. Proceedings – Working Conference on Reverse Engineering, WCRE. 214 – 223. 10.1109/WCRE.2004.10.

An Exploratory Study of Factors Influencing Change Entropy

Fri, 22 Oct 2021 00:00:00 +0000

🔀 L’entropie de Shannon, désigne la quantité d’informations qu’une source émet, donc l’incertitude concernant ce qu’elle va émettre. De même, l’entropie d’un logiciel mesure le niveau de complexité d’un code, donc son incertitude.

🔬 L’idée d’appliquer l’entropie de Shannon comme mesure logicielle vient de Warren Harrison, dans un papier de 1992. L’idée a fait du chemin, jusqu’à devenir un Leprechaun, comme à l’accoutumée.

🤌 Aujourd’hui, un papier publié en 2010 par 4 Italiens, qui analyse les facteurs qui influencent l’entropie du logiciel.

➕Le refactoring semble être le seul moyen de juguler l’entropie, voire de la réduire.
➖Plus il y a de développeurs successifs sur un morceau de code, plus l’entropie augmente vite.
〰️L’usage de patterns n’a aucun effet sur la progression de l’entropie.

SOURCES

C. E. Shannon, A Mathematical Theory of Communication, Bell system Technical Journal, 1948, DOI:10.1002/j.1538-7305.1948.tb01338.x

Harrison, Warren. “An Entropy-Based Measure of Software Complexity.” IEEE Trans. Software Eng. 18 (1992): 1025-1034. DOI:10.1109/32.177371

G. Canfora, L. Cerulo, M. Di Penta and F. Pacilio, « An Exploratory Study of Factors Influencing Change Entropy, » 2010 IEEE 18th International Conference on Program Comprehension, 2010, pp. 134-143, doi: 10.1109/ICPC.2010.32.

World of Warcraft, qu'en reste-t-il ?

Fri, 15 Oct 2021 00:00:00 +0000

Je suis de la génération Wrath of The Lich King, sorti lors de mes années lycée, en 2008. Je jouais sur serveur privé, un lycéen étant rarement fortuné. J’ai assisté ému à la cinématique de fin qui a marqué toute une génération. Je suis revenu en jeu à l’occasion de Shadowlands, dont le marketing cible clairement les anciens de WoTLK. Il serait osé de dire que le jeu se porte bien, pourtant l’œuvre artistique demeure impressionnante. Étrange paradoxe dont seul Blizzard a le secret et qui constitue un cas d’école de mécénat par crowdfunding, qui dure depuis 16 ans.

Ma madeleine de Proust

J’ai arrêté WoW lors de ma première année d’études, principalement à cause de querelles dans le staff, que le débranchement du serveur par la justice est simplement venu cesser. J’ai décroché, c’est peut être mieux pour moi, je n’aurai pas pu assumer mon temps de jeu longtemps sans échouer mes études.

J’ai suivi l’actualité de WoW d’un œil car certains camarades y jouaient, mais la perte de ma progression était trop récente et mon budget trop fragile pour jouer sur « offi ». En 2018, par le hasard de l’algorithme de YouTube, je tombe sur des remix de musiques du jeu. Les musiques réveillent des souvenirs d’adolescence, je les passe en boucle pour travailler, jusqu’à aujourd’hui. Puis vint LA musique. Celle qui venait récompenser des mois d’efforts intenses, la madeleine de Proust d’une nuit trop écourtée.

Invincible. Les souvenirs sont remontés d’un coup. Et j’ai replongé. Battle for Azeroth venait de sortir après un Legion dont tout le monde faisait l’éloge. J’ai créé un mage, une classe nouvelle pour moi. Et j’ai passé bien trop d’heures à ne pas jouer à BfA. La magie n’opérait pas. Trop de choses avaient changé dans le jeu, le gameplay et la communauté. Et je n’avais plus le niveau d’antan. J’ai donc commencé à devenir un touriste, un joueur qui explore tranquillement l’ancien contenu. J’ai redécouvert Burning Crusade et surtout WoTLK, terminant l’ensemble du contenu sur près d’un an.

Ma playlist ne se limitait pas à ces contenus. C’est d’abord par l’oreille que j’ai connu Mists of Pandaria, Warlord of Draenor ainsi que Cataclysm. J’ai parcouru l’ensemble du contenu, là aussi, sur encore une autre année.

En 2020, Shadowlands est sorti, avec ma génération de joueurs pour cible. Uther, Arthas, Bolvar, la Couronne de Glace et j’en passe. Après une introduction aussi épique qu’attendue et un premier raid vraiment amusant, j’ai eu l’impression de revenir dans un monde que je n’avais jamais quitté. La différence avec l’extension précédente ? J’ai trouvé une petite guilde accueillante. Dans ce grand creux entre la 9.1 et une suite, qui pourrait arriver tard et se révéler une mauvaise fin, j’ai arrêté de jouer. Farmer n’est pas amusant et le gameplay schlingue la sauce trop allongée, le wokisme et la manie de l’e-sport n’arrangeant rien.

Pourtant, même dans cet immense naufrage vidéoludique, Blizzard garde le cap sur deux invariants. Et quels invariants ! Les raids et le contenu artistique, les deux choses qui rendent le jeu unique. Les raids hebdomadaires en guilde restent ma seule activité sur le jeu et je ne regrette pas de payer mon abonnement au plein tarif.

Du crowdfunding artistique qui fonctionne ?

En vérité, je ne paie pas mon abonnement mensuel pour exploiter en boucle un contenu trop répétitif. Je vois mon abonnement comme un mécénat envers l’équipe artistique à l’origine du jeu. Je paie une œuvre immense qui survivra à notre temps, pas des serveurs trop vite débranchés à l’échelle de notre histoire.

Sylvarden, dans l’extension Shadowlands. Le niveau ne faiblit pas.

J’ai l’intime conviction que ces musiques, ces récits, ces paysages, nous survivront même si leur support technologique passe. Les non-joueurs n’ont pas plus que les hardcore gamers la chance de se plonger dans cette immense œuvre audiovisuelle, d’une richesse et d’une longévité incroyable. WoW marque, car s’il y a bien un élément qu’aucune extension n’a négligé, c’est la direction artistique. De grands compositeurs sont sortis des rangs de Blizzard et tous ont laissé leur trace dans un nouveau genre musical, enfant de la musique de film, sans en être le clone.

Même lors des pires creux dans le contenu, même lorsque des décisions déplorables, un management toxique ou une pandémie mondiale rendent le jeu médiocre en tant qu’artefact ludique, WoW reste l’immense œuvre artistique qu’il a toujours été. Je ne garantis pas que je continuerai à jouer si la crise actuelle persiste. Je continuerai cependant d’apprécier l’œuvre que Blizzard laisse en héritage au monde (que ses avocats soient d’accord ou non). Je continuerai de savourer la musique, un peu partout, le lore grâce à l’immense Sam Vostok et les décors par une plongée occasionnelle dans l’ancien contenu. Et parfois un raid avec des gens que j’apprécie, même si j’ai fait le deuil il y a des années de mon ancien niveau.

Un historien prend le pari d’expliquer l’histoire et ses leçons à travers celle de Warcraft.

Pour toutes ces expériences artistiques et sociales, malgré tout, merci ^{Non, pas toi.}~~Activision-~~Blizzard.

Maître-développeur, ma check-list

Thu, 09 Sep 2021 00:00:00 +0000

Je ne suis pas un maître ès développement, mais j’aspire à le devenir. Hélas, avec la disparition des ordres professionnels et la Loi Le Chapelier, il n’y a plus de maîtres en France. Je me suis donc résigné, sans maître. Cette déclaration peut paraître d’un orgueil fou, mais notre profession est neuve, surtout en France. Les anglo-saxons n’ont pas cette culture corporative propre aux pays latins, rien n’est à attendre d’eux. Faute d’alternative, je me lance, quitte à me planter. Faute de corporations pour faire des maîtres, je me ferai moi-même maître.

Les chambres des métiers proposent bien d’obtenir un titre de maître-artisan, mais à en juger les conditions, ce n’est que l’ombre de ce que furent les maîtres de l’âge d’or de l’artisanat. Il n’y a pas non plus d’Ordre des Développeurs et il n’y en aura probablement pas avant longtemps, tant les tentatives restent au point mort depuis plusieurs années. C’est donc contraint que j’entame cette démarche de me fixer moi-même des objectifs avant de pouvoir m’afficher comme maître-développeur la conscience tranquille.

Cette check-list est personnelle, mais j’invite chaque lecteur à l’augmenter ou la critiquer.

La check-list

Maintenir un logiciel en production depuis au moins 10 ans sans redémarrage du projet.
Avoir 10 ans d’expérience réelle.
Créer un chef d’œuvre et le présenter à 5 développeurs reconnus par la communauté francophone.
Avoir donné un talk dans un évènement d’envergure internationale.
Avoir publié un article dans une revue à comité de lecture.
Avoir fixé la problématique de ma thèse et avoir trouvé un moyen de la débuter en restant indépendant, sans contrainte de délais.
Avoir accueilli 3 stagiaires sur des périodes longues (> 2 mois). Cela suppose la fin des travaux de l’atelier (actuellement en second œuvre).
Publier une réécriture du mon mémoire de Master, largement insatisfaisant.
Devenir éditeur d’un logiciel commercial.

A ce jour, aucune de ces conditions n’est satisfaite. Les deux premières sont les plus proches, en 2023 précisément. Je publierai mon avancement sur le fil.

J’espère que cette démarche portera ses fruits et amènera à la structuration de notre profession. Nous ne pouvons pas collectivement refaire les mêmes erreurs tous les 30 ans.

Méritis SIRH

Wed, 01 Sep 2021 00:00:00 +0000

Méritis/Mindquest - Septembre 2021 - Mars 2022 - Paris

Audit, développement et refactoring stratégique d’une API de gestion des données RH sous ASP.NET Core. Mise en place de nouvelles pratiques de développement et d’outillage CI. Réduction de la dette technique en parallèle d’échéances de livraison.
Mission suivie d'une prestation de développement d'un middleware de gestion des logs ASP.NET Core en TDD.

Mon arrivée sur le projet SIRH devait être celle d'un renfort, pour aider une équipe en difficulté à sortir à nouveau des fonctionnalité. Il s'est rapidement avéré que le problème n'était ni l'héroïsme des équipes, ni l'environnement humain, mais bien un code lordement endetté par des pratiques inadaptées.

Refaire le projet n'était comme souvent pas une option. Un audit a été conduit afin d'identifier les noeuds de complexité les plus problématiques. Un report des échéances a été négocié afin d'en résoudre le plus possible par ordre de priorité. Manque d'architecture, tests bâtard (ni d'intégration, ni vraiment fonctionnels) et code peu lisible ont été les principaux noeuds de complexité adressés.

Lorsque les reports sont devenus intenables, l'équipe a mis le projet en convalescence. Les livraisons de fonctionnalités prioritaires ont repris, plus lentement qu'auparavant cependant, afin de dégager du temps pour poursuivre l'assainissement.

Ma mission s'est terminée à cette période. J'ai ensuite été sollicité pour réaliser un middleware générique de gestion de logs pour ASP.NET Core. L'outil était intégralement réalisé en TDD et fut aussi un bon amusement vu le niveau en C# requis (réflexion, Expressions, tests récursifs, etc.)

Qu'est-ce que l'appartenance du code ?

Sun, 22 Aug 2021 00:00:00 +0000

🔏 L’appartenance du code désigne le sentiment de responsabilité d’un développeur ou d’une équipe sur un morceau de code. Une forte appartenance est corrélée avec un plus faible nombre de défauts.

⛓️ La forte appartenance désigne un modèle où un code est presque exclusivement édité par ses contributeurs majeurs, à savoir des développeurs s’identifiant comme experts sur cette partie précise du logiciel.
Elle s’oppose à la faible appartenance, où la part des modifications réalisées par des contributeurs mineurs est grande.
Il existe également un phénomène de non-appartenance, désignant l’abandon de parties entières du code, assimilable au code legacy.

🪲 Dans leur étude de 2011, Bird et al. démontrent qu’un modèle de faible appartenance provoque plus de défauts, principalement à cause du manque de connaissance métier des contributeurs mineurs. La littérature précédente appuie ce point : la productivité d’un développeur dépend bien plus de la connaissance du métier de de son expérience précédente.

🧠 Sedano et al. reprennent ces résultats en prenant en compte les critiques de Brendan Murphy : le lien entre qualité et appartenance n’est pas seulement causé par la connaissance du métier, mais également par la psychologie. Un développeur ayant le sentiment d’être responsable d’un code y prêtera plus d’attention car il s’y identifiera (Quality with a Name).

📐 Délimiter arbitrairement des « parties du code » et nommer des responsables n’a qu’un effet très marginal sur la qualité et augmente le Facteur Bus, donc le risque projet !

✔️ Combattre l’apathie logicielle suppose la compréhension des ressorts psychologiques derrière le sentiment d’appartenance. Ultimement, Sedano et al. défendent la propriété collective du code comme une pratique vertueuse, mais la démonstration est pour demain !

— SOURCES —

Todd Sedano, Paul Ralph, and Cécile Péraire. 2016. Practice and perception of team code ownership. In Proceedings of the 20th International Conference on Evaluation and Assessment in Software Engineering (EASE ’16). Association for Computing Machinery, New York, NY, USA, Article 36, 1–6. DOI:10.1145/2915970.2916002

B. Murphy Code ownership more complex to understand than research implies. Software, IEEE, 32(6):19, Nov 2015

J. Shore, Quality With a Name, 2006

L'angoisse du sommeil

Tue, 17 Aug 2021 00:00:00 +0000

Certaines personnes sont génétiquement des couche-tard. J’en fais partie et du lycée à ma démission l’an dernier, j’en ai beaucoup souffert. Dans ce témoignage, j’explique ce que cela implique et comment je m’en suis libéré.

Cet article est un témoignage. Il n’a aucune valeur scientifique. Il n’a pas à être utilisé pour une quelconque revendication. Cela paraît évident, mais à l’heure d’Internet il faut le rappeler.

Je sais grâce à des tests génétiques grand public que j’ai de fortes chances d’être un couche-tard. Je n’ai pas attendu ce test pour m’en douter, mais poser un mot sur cette angoisse du lever qui m’a suivie de l’adolescence jusqu’à la fin de mes années de salariat me soulage.

La vie dans une société matinale

Mes années lycée furent les pires de ma vie.

Biologiquement, je suis inapte au travail intellectuel avant 10h du matin et suis incapable de m’endormir avant 1h, mais bien reposé je peux travailler jusqu’à 23h.

Le bus scolaire pour me rendre au lycée passait à 7h. Pour diverses raisons, je n’étais pas interne.

J’arrivais fatigué au lycée, au point d’avoir certains matins des rêves éveillés dans le bus. J’étais frustré de ne rien comprendre à des matières que j’appréciais au collège. De ne pas arriver à réfléchir de la journée, comme si j’avais un QI de 30. Je m’étais habitué à avoir une certaine aisance intellectuelle depuis la maternelle et là plus rien, le trou noir.

Le midi, je me gavais de sucre et de Red Bull stocké dans mon casier pour tenir le coup. J’avais parfois des emballements cardiaques, qui ne me perturbaient pas plus que ça à l’époque.

Le soir, à nouveau 1h de bus, puis le pire moment de la journée : les devoirs. Certains soirs mon cerveau disait stop, n’arrivant même plus à calculer une division simple ou à se remémorer un évènement historique.

Pour autant, je ne parvenais pas à m’endormir avant minuit, écoutant NRJ sur mon baladeur MP3. C’était mon seul moment de divertissement de la semaine. Les week-end servaient à éponger ma dette de sommeil.

Les vacances scolaires étaient une planche de salut, un radeau de fortune vite englouti à nouveau par une mer démontée. Ce calvaire a duré 3 ans.

Puis je suis devenu étudiant en informatique à Bordeaux. J’avais 16 ans, un petit appartement proche de l’école. Ma condition s’est améliorée. J’ai repris goût au travail intellectuel et à la vie sociale. Les cours commençaient à 9h, ce qui est acceptable, avec 30 min de trajet matinal à pied pour me réveiller. Lever : 8h15. Une chocolatine et un café sur le trajet à la boulangerie pour gratter la moindre minute de sommeil.

Gratter la moindre minute de sommeil.

Suite au traumatisme du lycée, c’était devenu une obsession. Retard savamment calculé pour être disciplinairement acceptable, micro-optimisation de la routine matinale, jusqu’à sécher certains cours avec des excuses douteuses pour gagner une heure dans la semaine : j’en étais là. Même les soirées, évènement indispensable de la vie étudiante, étaient acceptées, déclinées et écourtées en fonction de cet indicateur : quel impact sur la dette déjà importante de sommeil que je traînais ?

Mon addiction au sucre n’a pas cessé pendant mes études et le café s’est invité dans mes journées avec une consommation débridée pendant 2 ans (9 à 13/jour). C’était le prix que mon cerveau réclamait pour continuer.

L’alternance est venue se greffer à cette mécanique rodée, avec des semaines en entreprise où le lever était obligatoire et des cours devenus variable d’ajustement, donc de plus en plus fréquemment séchés le matin. Pour aller travailler, il fallait que je prenne la route et je ne compte pas les comportements dangereux à cause de la fatigue sur les boulevards. Il m’est arrivé plusieurs fois de somnoler au volant et de reprendre le contrôle in extremis sur l’autoroute en rentrant chez mes parents pour le week-end.

Vint la fin des études et le temps du travail. Plus d’excuses et d’absences faciles. Le retard matinal était plus ou moins accepté selon la culture de l’entreprise où j’étais amené à intervenir. La moindre minute de sommeil était comptée et recomptée, comme une pièce dans la bourse d’un avare. J’ai appris à haïr les daily, rituel agile commun dans les équipes de développement, sans aucune raison valable. Simplement parce qu’ils étaient en plein dans ma période d’éveil. Avec l’habitude, j’ai appris à conduire (sur la rocade, donc très dangereusement), dans un état de demi-sommeil.

En janvier 2020, c’était la mission de trop en ESN. Trop loin de chez moi, dans un environnement urbain que j’abhorre, avec des embouteillages, pour retrouver toujours les mêmes antipatterns 1000 fois constatés en entreprise. J’ai posé ma démission. Elle fut effective lors du premier confinement.

C’était terminé. Plus jamais ça. Le repos, enfin.

La joie simple de l’indépendance

Depuis que je suis indépendant, ma routine, que je ne cache d’ailleurs pas à mes clients, est de 10h-22h avec un pause le midi et le soir. Je n’ai jamais été aussi productif et apaisé de ma vie.

Parfois, mes missions d’enseignement ou d’installation sur chantier me font me lever tôt, parfois 6h00, parfois 8h00. Cela ne me pose aucun problème et je suis même heureux de casser la routine. Ce sont des missions courtes et j’ai amplement le temps de dormir après pour compenser. Même chose pour les soirées, où je peux passer un bon moment sans regarder ma montre.

J’ai perdu cette obsession de l’heure de sommeil.

Complètement.

Je réalise désormais d’où viennent ma phobie des missions longues et mon refus catégorique de la régie et du travail en équipe de développement. Outre l’immense liberté d’organiser mon emploi du temps, devenue indispensable avec un chantier de rénovation en cours, travailler avec des lève-tôt qui imposent leurs horaires, contractuellement ou par pression sociale, ne me convient pas.

J’ai pété les plombs à deux reprises et rompu le contrat de prestation à chaque fois. Les antipatterns expliquent mon choix, la phobie des horaires matinaux expliquent la brutalité à laquelle j’ai choisi de cesser les prestations.

Mon meilleur code est fait aux alentours de 20h, sur un fond de Graham Plowman ou de Russell Brower. C’est un fait que j’ai constaté et mesuré. Et à cette heure là, la plupart des gens normaux ne travaillent pas.

Je n’ai aucun problème avec les relations professionnelles au long cours. Mon plus ancien client date d’avant même la création de mon entreprise et la plupart de mes clients actuels remontent à plus d’un an.

J’ai en revanche horreur des horaires imposés au-delà de quelques jours. J’ai trop souffert et ça n’est ni dans mon intérêt, ni dans celui de mes clients, tant mon travail matinal est médiocre et mon humeur massacrante. J’y mets de préférence les paperasses ou les taches routinières comme les mails ou le nettoyage de code. J’ai arrêté de développer des features avant 11h, c’est à jeter presque à tous les coups.

Conclusion

Notre société a une norme concernant les horaires standards, calquée sur ceux de la majorité de la population, plutôt lève-tôt (et encore, je me demande si une étude à été faite, tant les articles de magazines féminins « 10 conseils pour se lever du premier coup« , scientifiquement débiles, pullulent) et monophasique (ce qui n’a pas toujours été la norme).

Loin de moi l’idée de contester une norme pour qu’elle s’adapte à une minorité. Ce n’est pas mon propos, une société fonctionnelle a besoin de normes et de codes sociaux. Mon témoignage a plutôt pour but :

De montrer aux couche-tard que dans certains métiers (les développeurs sont très privilégiés) il est possible de s’adapter, en devenant indépendant par exemple.
D’alerter les lycéens et étudiants de mon entourage : si vous êtes dans ce cas, réfléchissez dès maintenant au métier que vous allez exercer. Votre bonheur et votre espérance de vie en dépendent.
De témoigner, tout simplement, je sais que certaines personnes en ont besoin, pour mettre des mots sur ce qu’elles vivent.

Si je peux être utile à quiconque, qu’il me contacte.

Avertissement

Mon article ne se substitue pas à l’avis d’un médecin du sommeil.

Si vous vous levez fatigués malgré un temps de sommeil qui vous semble suffisant.
Si vous n’avez pas d’autre choix que de vous lever tôt et que vous devez forcer votre cycle (métiers du bâtiment, artisans, militaires, etc.)
Si vous avez des insomnies, donc que vous n’êtes pas vraiment « couche-tard », juste « pas endormi du tout ».
Pour tout autre trouble (alcool, excitants, etc.)

CONSULTEZ ! (un médecin du sommeil, pas un chaman, un rebouteux ou un dealer).

Le monde a-t-il oublié Manny Lehman ?

Mon, 16 Aug 2021 00:00:00 +0000

Émises par Meir « Manny » Lehman, comme une tentative pour donner à la science du logiciel des assises théoriques solides, les 8 lois de Lehman ont été oubliées. Les générations de chercheurs qui les ont étudiées ne les ont pas invalidées, bien au contraire ! Il serait donc temps d’adopter ces lois, selon le vieux principe scientifique qui veut que toute hypothèse réfutable restée solide face aux tentatives de réfutation est temporairement une connaissance fiable.

EDIT 19/08/2021 : mise à jour du texte de la 3ème loi, trop obscur. Ajout de références.

Les lois de Lehman ont été émises tout au long du dernier quart du XXème siècle. Elles sont passées de trois au milieu des années 70 à huit en 1998. Les trois premières sont tirées d’une analyse des données de gestion de projet d’IBM en 1968. Les suivantes ont été ajoutées au fil du temps et des discussions de Lehman avec d’autres chercheurs.

Toutes décrivent les lois empiriques que suivent les développements de programmes de Type-E. Ces lois restent valides même si les développeurs les ignorent ou luttent contre (d’où le vocable de lois).

Les logiciels de Type-E sont les logiciels réalisés pour répondre à un besoin métier complexe dans le monde réel, par opposition aux programmes de type P et S.

Les lois de Lehman

I – Changement continu

Un programme en cours d’utilisation doit être continuellement adapté où il deviendra de moins en moins satisfaisant.

La première loi est simple et instinctivement connue des développeurs et du management. Le monde évolue autour du logiciel, le logiciel doit évoluer en permanence pour répondre aux exigences d’un monde qui change.

Un logiciel doit être maintenu dans le temps pour durer, par des actions de maintenance régulières et adaptées.

II – Complexité croissante

La complexité d’un programme augmente à chaque modification, tant qu’aucune action n’est entreprise pour réduire celle-ci.

Cette seconde loi est tout aussi connue des développeurs. Elle est en revanche ignorée ou niée par les managers. De surcroît, les développeurs sont souvent bien incapables de l’expliquer à leurs décideurs, ils ne la connaissent que d’instinct.

Crédits: Commitstrip

Le drame est le lien entre complexité du logiciel et vélocité. Les équipes s’embourbent dans la gestion d’une complexité accidentelle évitable et ne parviennent plus à sortir de features. La pression du management s’accentue et la pire réponse est apportée presque à chaque fois : réduire le rythme du refactoring pour « gagner du temps ». Le schéma est ensuite toujours le même : surendettement, démotivation, turnover, retards, etc.

III – Auto-régulation

L’évolution d’un logiciel est un processus autorégulé. Les mesures des attributs des process et du produit suivent une distribution normale.

Cette loi est la plus barbare de la série et ses nombreux changements de nom et de définition semblent indiquer que Manny Lehman lui-même a du mal à expliquer cette loi au public.

1978 : Loi de la croissance statistiquement régulière / Law of Statistically Smooth Growth
1980 : La loi fondamentale de l’évolution des grands programmes / The Fundamental Law of Large-Program Evolution
1998 : Auto-régulation / Self-Regulation

Cette loi décrit l’inertie des projets logiciels, inertie d’autant plus grande qu’ils impliquent un grand nombre d’acteurs. Pour Manny Lehman, plus un projet logiciel avance, moins les parties-prenantes ont de prise sur sa progression. Il exprime en 1980 la troisième loi sous cette forme :

L’avenir d’un projet logiciel dépend plus de son passé que des choix présents.

La loi a été remaniée par l’auteur en 1998, suite à l’ajout de la huitième loi. L’ancienne version de la troisième loi devient un lemme, qui facilite la compréhension de la nouvelle version.

Un projet logiciel ressemble à une partie de curling. Le lancer initial détermine la majorité des facteurs qui feront la réussite ou l’échec d’un projet. Les balayeurs ont un rôle important, mais plus minime que le lanceur sur la direction et la longévité du projet. Si le lanceur a projeté la pierre vers les tribunes, aucun effort des balayeurs n’ira la remettre sur le chemin de la cible.

Autrement dit, après le lancer, les balayeurs ne peuvent plus choisir arbitrairement où ira la pierre. Leur rôle se bornera à une influence discrète sur la direction de celle-ci. C’est déjà beaucoup. Quelques centimètres séparent le centre de la cible, la réussite, d’une performance médiocre, le retard.

C’est cela que Lehman exprime par sa loi. Une fois le projet « sur les rails », les aiguillages sont rares. Aucune autorité ne peut décréter que la valeur de tel ou tel indicateur sera arbitrairement doublée ou triplée. Tout au plus l’équipe pourra influer sur certains indicateurs par petits incréments. Au prix, huitième loi oblige, d’une réaction inverse de d’autres indicateurs.

A un instant T, l’ensemble des indicateurs du projet suit toujours une distribution normale. La seule variable à portée de l’équipe et du management est σ. Faut-il laisser le projet suivre son cours, ou tenter de corriger un jeu de variables, au prix d’une réaction symétrique d’autres variables ?

Je prends un exemple : le management peut décider que le projet ne va pas assez vite et mettre la pression sur les développeurs. La variable « vitesse » va augmenter, au prix d’une baisse d’autres variables comme la qualité ou la vélocité à long terme. La distribution normale des variables reste respectée.

IV – Conservation de la stabilité organisationnelle (taux de travail invariant)

Le taux d’activité efficace global moyen sur un système en évolution est invariable dans le temps.

Lehman décrit la Loi n°4 comme étant la plus contre-intuitive. Il énonce tout simplement que le management n’a aucune prise sur la vitesse d’évolution du logiciel ! Trop de boucles de rétroaction sont en jeu, macro (marché du travail, concurrence, etc.) et micro (Loi de Brooks, motivation, etc.) pour permettre le moindre changement à court ou moyen terme.

Prenons un exemple : votre projet est en retard et vous souhaitez ajouter un développeur. Sa rémunération sera prise sur autre chose (refacto, endettement, réserves). De plus, la loi de Brooks vous annonce que toute l’équipe va être handicapée par l’arrivée du nouveau pendant un bon moment. Une nouvelle personne ajoute un risque humain (conflits, mésentente, etc.). Si d’aventure l’intégration se passe bien et que le nouveau ajoute suffisamment de vélocité à l’équipe pour éponger le retard originel, celui dû à son intégration et justifier sa rémunération, ça ne sera statistiquement pas le cas dans l’équipe voisine ou au recrutement suivant.

Le corollaire de la 4ème loi est que le seul levier possible pour augmenter significativement la productivité d’une équipe est d’adopter des pratiques plus efficaces, donc d’éviter le plus de gâchis logiciel possible. Les extreme programmers ne sont pas des héros, juste des économes.

V – Conservation de la familiarité

Au cours de la vie active d’un logiciel, le contenu des livraisons successives est statistiquement invariant.

A cause de boucles de rétroaction omniprésentes dans le développement, la quantité de valeur dans une livraison restera statistiquement la même au cours du temps.

Cette loi impitoyable ne laisse que deux leviers aux managers pour influencer le contenu des livraisons afin de coller au mieux au marché ou au besoin : la priorisation et la dette technique.

Cette loi est cruelle : tout manager qui met la pression sur ses développeurs pour livrer plus et plus vite se condamne inévitablement à réduire la valeur des livraisons lointaines. Jusqu’à rendre cette valeur négative lorsque plus de bugs sont livrés que de features, conduisant à un effondrement de la confiance des utilisateurs.

VI – Croissance continue

Le contenu fonctionnel d’un logiciel doit croître sans cesse pour maintenir la satisfaction des utilisateurs stable.

Cette loi ressemble beaucoup à la première, sans lui être identique (même si les deux phénomènes sont liés). Quand un nouveau logiciel est développé, il répond d’abord aux besoins les plus évidents et pressants de ses utilisateurs, qui ne seront alors plus bloqués par une absence de solution. Ces utilisateurs seront alors bloqués par de nouveau problèmes, au fur et à mesure que les précédents seront adressés. La frustration sera sans cesse reportée sur l’attente de nouvelles features ou l’amélioration de l’existant. Si la croissance d’un logiciel vient à cesser, cette frustration n’a plus d’exutoire et la satisfaction des utilisateurs vient à diminuer.

Ce phénomène n’a pas de fin, car les utilisateurs ont tendance à pousser toujours plus loin l’intégration de leurs process dans le logiciel.

VII – Déclin de la qualité

Tout logiciel sera perçu comme en déclin de qualité s’il n’est pas rigoureusement maintenu et adapté à un environnement opérationnel changeant.

Encore une loi ressemblant à la première, lui étant reliée, mais fondamentalement différente dans son objet. La 7ème loi est la conséquence du Principe d’Incertitude : le résultat de l’exécution d’un programme dans le monde réel est intrinsèquement incertain et les domaines précis de cette incertitude ne sont pas non plus prédictibles.

« Le monde change par glissement, de manière inéluctable mais prévisible » est la prémisse de la première loi.

« Le monde change aussi par ruptures, imprévisibles dans leur intensité et leur fréquence » est la prémisse de la septième loi.

Sa conséquence directe est la nécessité de garder le logiciel en permanence dans un état d’ouverture au changement maximal. Tout doit pouvoir être remis en cause du jour au lendemain si la satisfaction de l’utilisateur l’exige.

Statistiquement, le pire arrivera un jour. Et il faudra s’y adapter.

VIII – Système rétroactif

Les processus de développement des logiciels sont constitués de boucles de rétroaction récursives sur de multiples niveaux. Ils doivent être traités comme tel pour être modifiés ou améliorés avec succès.

Cette loi peut être vulgarisée en présentant une équipe de développement comme un organisme vivant complexe. Appliquez-lui un changement, elle fera tout pour retrouver son état initial. Augmentez le rythme des livraisons, elles s’amaigriront. Pressez la cadence, la dette viendra engluer l’équipe sur le long terme. Recrutez un nouveau, les relations humaines entre les membres deviendront plus confuses et moins efficaces.

Cette loi avertit les managers tentés par le néo-taylorisme logiciel : les développeurs ne sont pas de ouvriers à la chaîne. On ne peut pas augmenter facilement la productivité d’une équipe. Toutes les solutions simples sont vouées à l’échec, même s’il n’arrive que plus tard. Tout changement doit avoir comme présupposé l’équipe actuelle et le changement doit venir d’elle.

Le logiciel n’obéit pas aux règles classiques de la gestion de projets industriels. La qualité logicielle est une discipline à part, complètement distincte, qui, c’est mon avis, ne peut être pratiquée que par des praticiens en développement correctement formés et expérimentés.

Limites et controverses

Dès leur sortie dans les années 1970, les lois de Lehman ont provoqué deux types de controverses : celles sur le terme de lois et celles sur le contenu de celles-ci. Les débats ont été vifs jusqu’à l’aube des années 2000, avant qu’elles ne tombent dans l’oubli.

Les détracteurs de Lehman ont-ils réfuté les lois ? En 2013, 4 chercheurs ont réalisé une revue systématique à ce propos.

Evidence Pyramid.

Le consensus actuel semble valider totalement les lois de Lehman pour les logiciels commerciaux. Cependant, la plupart des lois sont réfutées pour le développement Open-Source, qui semble suivre sa propre logique.

Les lois de Lehman font partie de ce que la recherche en qualité logicielle a de plus solide à l’heure actuelle pour décrire et bâtir des équipes et process solides. C’est un fait scientifique solide en l’attente de nouvelles preuves.

Le terme de « Lois » utilisé par Lehman a créé son lot de controverses, auxquelles l’auteur lui-même a répondu dans son article de 1996, Laws of Software Evolution Revisited. Je ne souhaite pas allonger cet article en présentant cette controverse, qui n’apporte rien après 40 ans et des dizaines d’articles venant confirmer les lois de Lehman.

Conclusions

Bien que tombées dans l’oubli, les lois de Lehman méritent de devenir une partie du corpus de règles de l’art qui gouvernent notre profession. Leur force probante est suffisante pour permettre à tout développeur de les opposer à sa hiérarchie ou à d’autres développeurs. Elles sont tout simplement au-dessus de l’avis de tout expert, même le plus reconnu et respectable. A l’heure des software-gurus, nous avons besoin de cette stabilité et de cette rigueur.

Je les enseigne à mes étudiants et j’invite tout développeur à les apprendre et à les comprendre. La recherche en qualité logicielle n’a pas atteint le niveau de rigueur de la recherche médicale (les méta-études sur ce champ de recherche se comptent sur les doigts de la main), cela ne signifie pas pour autant qu’elle ne démontre rien. L’appropriation des résultats de la recherche par les développeurs est un cercle vertueux. Plus nous exigerons des connaissances fiables pour guider notre profession, plus nous pousserons les chercheurs à les produire. N’hésitez d’ailleurs pas à remercier par un simple mail les chercheurs des études que vous lisez, d’expérience ils sont très heureux de voir des praticiens lire et appliquer leurs travaux.

Je compte continuer ce travail sur les lois et les règles de notre art, je le pense salutaire si vous voulons apprendre et sortir de l’enfance de notre profession.

Sources

M. M. Lehman. 1996. Laws of Software Evolution Revisited. In Proceedings of the 5th European Workshop on Software Process Technology (EWSPT ‘96). Springer-Verlag, Berlin, Heidelberg, 108–124.

M. M. Lehman, “Programs, life cycles, and laws of software evolution,” in Proceedings of the IEEE, vol. 68, no. 9, pp. 1060-1076, Sept. 1980, doi: 10.1109/PROC.1980.11805.

M.M. Lehman, On understanding laws, evolution, and conservation in the large-program life cycle, Journal of Systems and Software, Volume 1, 1979, Pages 213-221, ISSN 0164-1212, DOI:10.1016/0164-1212(79)90022-0.

Israel Herraiz, Daniel Rodriguez, Gregorio Robles, and Jesus M. Gonzalez-Barahona. 2013. The evolution of the laws of software evolution: A discussion based on a systematic literature review. ACM Comput. Surv. 46, 2, Article 28 (November 2013), 28 pages. DOI:10.1145/2543581.2543595

Pont SEPA-Chargebee

Fri, 01 Jan 2021 00:00:00 +0000

SNAL/CBC Consult - Janvier 2021 - Mai 2021 - Région de Mulhouse

Développement au forfait d’un automate de traitement des débits et rejets entre le logiciel de facturation Chargebee et le format XML SEPA DirectDebit.

L'intérêt de ce projet, somme toute assez routinier, est d'être une démonstration achevée des bonnes pratiques que je prêche. Le besoin ne présente aucune difficulté particulière : il s'agit d'un pont très classique entre un logiciel de facturation (Chargebee) et le format d'échange interbancaire SEPA. Le pont fonctionne dans les deux sens : émission des ordres de débit et lecture des rejets.

Quelques détails sont inconnus au début du projet, certaines dépendances obligatoires sont intestables ou peu sûres, des couches anticorruption ont du être mises en place afin de rendre l'intestable plus prédictible et le peu sûr facilement remplaçable. Les détails d'implémentation dépendent du métier et non l'inverse (DI) et chaque composant, en plus d'être testé individuellement (tests fonctionnels), est mis en mouvement dans un tout plus grand (tests système), avant d'être relié au monde extérieur pour les tests les plus aboutis (tests d'intégration).

Le projet est réalisé en C# avec une architecture hexagonale. Cette architecture offre une grande surface d'accroche à d'autres bonnes pratiques, comme TDD, DDD, l'utilisation d'un framework d'IoC ou l'usage de tests de recette pour les démonstrations. La conjonction de ces techniques représente le sommet de la qualité dont j'étais capable lors de la sortie du projet.

Nous nous attendons à ce que ce projet soit détrôné par un autre, nos connaissances progressant sans cesse.

Se former en artisan

Sat, 07 Nov 2020 00:00:00 +0000

En entreprise, il est rare que l'on puisse choisir ses formations. L'anticipation des besoins par le management détermine souvent le calendrier. Chez l'indépendant et plus encore l'artisan, se former tient de l'exigence et de la discipline personnelle.

Préparation de boutures, en vue de créer des haies. Une des premières choses à faire en s'installant c'est de délimiter les espaces.

Avoir arrêté le salariat puis la régie m'ont permis de reprendre le contrôle de mon temps. Ne plus avoir un client à temps plein, mais plusieurs en parallèle offre de nombreux temps morts, de quelques heures à plusieurs jours. Les plus longs sont employés à renforcer mon autonomie. Quelque soit la saison, les travaux ne manquent pas. Les plus courts offrent moins de liberté. Sortir puis ranger les outils prend du temps. De surcroît, le cerveau déteste les changements de contexte et perd du temps à s'y retrouver. Mieux vaut donc rester dans le même type d'activité. La formation continue est une bonne candidate pour occuper ces espaces libres de moyenne taille, entre une demi-journée et une heure. En deçà, une pause reste le meilleur investissement.

Voilà réglée la question de "quand se former". Mais que faire ? Je vous livre ma recette personnelle, sans prétendre avoir une quelconque autorité.

Je me forme en utilisant 3 familles de sources, chacun ayant sa propre temporalité. Ce diagramme résume grossièrement l'intérêt de chaque source. La science et les livres offrent un savoir solide, vérifié et souvent conçu pour durer. Ce n'est pas la priorité sur Internet, qui est plus volontiers un lieu de débats et d'essais. Ce schéma simplifie la réalité. Des blogs comme ceux de Mark Seemann ou de Martin Fowler n'ont rien d'éphémère et il n'est pas rare de voir un chercheur ou un éditeur publier sur le sujet à la mode. Comme tout modèle, ce diagramme est faux, mais utile.

La suite de ce papier présente chacune de mes sources de connaissance. Vous pouvez sauter directement à celle qui vous intéresse.

Bâtir un socle : les livres.
L'avis des praticiens : vidéos, blogs, podcasts.
L'état de l'art : papiers de recherche.

Les livres

Chaque métier a ses auteurs de référence. Le nôtre n'y échappe pas. Martin Fowler, Uncle Bob Martin, Osherove, Hunt&Thomas, etc. Je ne ferai pas la liste complète de ma bibliothèque pro, vous trouverez des listes de "Must have" à foison sur Internet. Un bon livre est une somme de savoir robuste, une brique de base dans la formation continue d'un développeur.

Le coût des ouvrages techniques est un premier frein à l'acquisition. 50€ n'est pas un prix exceptionnel pour ce genre d'ouvrages, gros et à faible tirage. Les plus demandés sont rarement disponibles d'occasion. Cet inconvénient est accentué pour les auto-entrepreneurs, qui ne peuvent pas acheter ces ouvrages net de TVA. Enfin, j'ai horreur d'annoter les livres, ce qui oblige à multiplier les post-it peu élégants.

Quelques classiques que je recommande.

Avoir des livres est obligatoire pour un développeur, on ne peut pas faire sans et tout savoir supplémentaire s'appuiera sur ce socle. Si vos étagères sont vides, je recommande de commencer par là. Ce n'est qu'ensuite que vous pourrez explorer ce que les chercheurs et les praticiens ont produit de plus récent.

Pour trouver des bons livres, j'ai deux méthodes : demander des recommandations dans la communauté et regarder les livres les plus cités dans les papiers scientifiques. J'ai ainsi de bonnes chances de ne pas investir dans des ouvrages décevants. Je me prive des dernières sorties, mais je l'accepte car ce n'est pas pour cela que j'acquiers des livres.

Avantages	Inconvénients
Haute densité de connaissances	Savoirs fondamentaux
Prix élevé

Papiers de recherche

La collecte et la lecture de papiers de recherche représente environ 2/3 de mon temps de formation. Environ la moitié est de la lecture. Le reste est employé à suivre les références, classer, imprimer et télécharger les articles.

Les articles scientifiques sont complémentaires des livres : ils apportent des connaissances fraîches, tout en restant solides donc capitalisables sur le long cours. Toutefois, les articles ne sont pas à la portée de n'importe qui.

Un débutant aura mieux fait de lire les classiques et de pratiquer quelques années, sans quoi le savoir scientifique risque de lui paraître aride et très abstrait, faute qu'il ait rencontré des cas d'applications dans sa maigre expérience.
Un anglophobe n'aura simplement pas accès à 99,99% des papiers. L'anglais étant le latin de l'informatique, s'y mettre n'est pas une option.
Une personne non-familière avec le formalisme des articles scientifiques et les circuits de validation ne saura pas estimer correctement le degré de confiance à accorder à un article.

Ces précautions signalées, je vais partager ma méthode. Cela fait 3 mois que je la raffine et l'emploie avec succès.

Tout commence avec une bête recherche Google Scholar sur des sujets très vagues. Plus ils sont vagues mieux c'est, nous verrons pourquoi ensuite.

Le classeur où je range les articles que je souhaite conserver.

Les résultats arrivent par mail, j'effectue un premier tri selon le titre. Puis selon l'abstract. Je stocke les articles intéressants pour les imprimer par lots (je déteste lire sur écran des documents longs).
Vient le temps de la lecture. J'effectue une première lecture superficielle rapide. Elle me permet de constituer 2 piles. La première sera relue plus en détail ultérieurement. La seconde ne servira qu'à en extraire les références intéressantes (c'est notamment le cas des méta-études, pas toujours utiles aux non-chercheurs).
J'extrais les références de tous les papiers lus. Elles seront mêlées aux résultat de Google Scholar afin d'effectuer l'itération suivante. Les livres référencés sont notés dans un carnet. Le livre le plus cité a de fortes chances d'être commandé.
Je classe les papiers que je souhaite garder par grands thèmes, avec pour chacun un post-it résumant son intérêt et éventuellement des marque-page. Ils sont intensément surlignés.

Un cycle complet prend environ une semaine. Je n'ai pas encore trouvé de méthode viable pour gérer les périodes d'intense activité scientifique. Pour l'instant les papiers non-lus s'accumulent sans constituer un inconvénient majeur. L'ordre de lecture est parfaitement arbitraire, je lis selon mes envies.

Avantages	Inconvénients
Savoir solide, souvent vérifié	Difficulté de lecture
Les techniques de demain	Tri long et difficile

Vidéos, blogs et podcasts

L'avis des praticiens est chez moi la dernière famille de sources par ordre de priorité. Cela pour de nombreuses raisons :

Tenir une veille à jour est éreintant. Tout bouge très vite. Un bon outillage est nécessaire, mais il ne fait qu'atténuer légèrement la pénibilité du travail de sourçage.
La communauté produit beaucoup de bruit et de drama. Beaucoup d'éminents professionnels ont du mal à séparer leur expertise de leurs opinions tranchées, surtout lors des grands évènements politiques. Quand les canaux "opinions" et "expertise" ne sont pas distincts, même le meilleur outil de veille est englué dans le bruit.
Je trouve tout simplement mon bonheur dans les deux sources précédentes. La solidité des grands auteurs mâtinée des dernières découvertes des chercheurs est un mélange efficace.

Une veille qui a été délaissée 2 ans n'est pas belle à voir.

Cela se ressent fortement sur ma veille, complètement délaissée et rongée par les placements de produit. C'est pourquoi je ne donnerai aucun conseil dans cet article. J'ai pour projet de remettre ma veille technique sur les rails, en capitalisant les connaissances acquises à l'École de Guerre Économique. Encore un article promis qui ne sera pas écrit avant des mois.

Avantages	Inconvénients
Immédiatement applicable	Qualité très variable
Facile à partager	Beaucoup de bruit et de drama
	Fort investissement pour garder sa veille à jour.

Conclusion

Nous sommes ce que nous mangeons. Cela vaut également intellectuellement. Avec Internet, la tentation du grignotage intellectuel est grande : se former uniquement à la technologie à la mode, en négligeant les ouvrages plus consistants qui nous charpentent l'esprit. Souvent plus difficile d'accès, ils ne livrent leurs secrets qu'à ceux qui prennent le temps d'apprendre à les cuisiner. Cela vaut pour les livres, mais surtout pour les papiers scientifiques. Contrairement à ses camarades d'autres sciences, l'étudiant en informatique n'entend jamais parler de recherche pendant ses études et n'a aucune formation à ce sujet. Si je n'avais pas croisé sur ma route la zététique et le monde de la vulgarisation scientifique, je serai passé à côté d'une source abondante et précieuse de connaissances.

Je termine par un sujet que je n'ai pas évoqué : YouTube ne remplace pas la présence physique aux évènements (colloques, salons, séminaires, etc.). Vous y trouverez plus que des conférenciers accrochés à un micro : une communauté de professionnels avec qui discuter. C'est fondamental.

Travaillez-vous sur site ou à distance ?

Tue, 01 Sep 2020 00:00:00 +0000

TLDR; Pour les missions d'audit, toujours sur site. Pour les formations, les parties magistrales peuvent être à distance, pas les TP/exercices/Katas, sauf le suivi des projets en fin de cours. Pour le développement, de préférence à l'Atelier, sauf si une phase du projet requiert ma présence sur site.

L'Atelier est d'abord le lieu où l'artisan travaille. Je passe la majorité de mon temps à façonner des logiciels dans un environnement que j'ai adapté à l'exercice efficient de mon art. Demanderait-on à un menuisier de produire une huisserie sur site, au cul du camion ? Le développement de logiciels requiert également un environnement de travail adapté à la main de l'artisan.

Toutefois, lorsque le projet le requiert (recueil du besoin, livraison, etc.), je me déplace dans vos locaux, sur le chantier ou dans tout autre lieu où ma présence serait nécessaire. L'échange humain direct, chargé d'implicite et de non-verbal, charrie une densité d'information qu'aucune technologie ne peut retranscrire. Ma vision de l'audit est intégrale : ne lire que le code c'est passer à côté du contexte qui l'a produit. Cela revient souvent à reproduire indéfiniment les mêmes erreurs. Tous mes audits se font en partie là où travaillent vos équipes.

En dehors des cas sus-mentionnés, il peut m'arriver d'accepter des missions "sur site", de courte ou moyenne durée. Je tiens à ce qu'elles restent l'exception. L'environnement de bureau ne m'a jamais paru propice à l'exercice de mon métier, qui nécessite d'alterner des phases sociales avec de longs silences studieux. Les explications sont ici.

J'arrête le télétravail

Tue, 01 Sep 2020 00:00:00 +0000

Je suis devenu indépendant en avril, pas forcément la meilleure période pour démarrer une activité. Après quelques missions courtes, j’ai décidé de tenter une mission longue en régie, majoritairement en télétravail. J’ai donc repris la routine du bureau, ses horaires, sa hiérarchie. Après 3 semaines, j’ai arrêté la mission. Le télétravail n’est pas ce que je croyais.

Ma principale erreur fut de confondre télétravail et autonomie, mission longue et régie, indépendance et artisanat. J’ai cru naïvement que le statut de freelance donne par lui-même une certaine autonomie, c’est une erreur : il est parfaitement possible de trouver des missions en simili-salariat via des ESN (avec tous les risques de requalification en CDI par les prud’hommes qui vont avec). Si, comme moi, vous êtes devenu indépendant pour être autonome, ce mode de fonctionnement ne vous conviendra pas.

Je suis un artisan du logiciel. Cela signifie que je veux porter la responsabilité complète de toute tâche que l’on me confie.

Je préfère ne pas être dans une équipe, étant entendu qu’il faut des années pour en composer une qui soit productive.
Je tiens à une relation entre égaux, étant antagoniste aux arguments d’autorité qui constituent l’essentiel des rapports hiérarchiques en entreprises. Je crois en la force de l’argumentation sourcée, même si celle-ci prend du temps pour être qualitative.
Je ne considère pas que le client soit roi et place les règles de mon art au-dessus de ses désirs, pour le bien commun.

En bref, je veux satisfaire un client ayant un besoin, non un employeur donnant des directives. Souvent, cela impliquera la production de logiciels, mais pas systématiquement. Ce choix est une question de fond, indépendante des tournures contractuelles capables de « simili-salarier » un indépendant. Le télétravail n’y change rien, sinon un peu de confort.

Cette unique mission en régie a été l’occasion de faire le point avec moi-même et de me rappeler pourquoi j’exerce ce beau métier. La liberté a ses défauts, principalement en France où être indépendant est un chemin de croix fort coûteux (URSSAF, compta, impôts, banques, etc.), mais après y avoir goûté je n’y renoncerai plus. L’authentique indépendance de l’artisan, propriétaire de son métier, seul responsable de sa formation et de son agenda, est trop belle pour être abandonnée.

Groupe Atlantic

Sat, 01 Aug 2020 00:00:00 +0000

Groupe Atlantic/Younup - Août 2020 - La Roche sur Yon

Développement C#/.NET en contexte industriel et domotique au sein d'une équipe de 12 (développeurs et testeurs).

Albus

Wed, 01 Jul 2020 00:00:00 +0000

SNAL/CBC Consult - Juillet 2020 - Région de Mulhouse

Audit des performances d’une application. Approche orientée code : profilage, tests unitaires puis réalisation de POC présentant les améliorations possibles de l’existant.

Créer une culture de la qualité logicielle

Mon, 01 Jun 2020 00:00:00 +0000

De mauvais incitatifs créent un jeu où le joueur a intérêt à produire du code médiocre. Avec le temps, le jeu évacue les fortes têtes et ne restent que les joueurs produisant un code médiocre. Est-ce fichu ? Non, à condition d'adopter une démarche stratégique.

Parlons indicateurs, performance et surtout incentives. J'ai encore vu cette stupidité sur une offre de mission en Devops :

Imaginons que je sois un joueur sans scrupules, dans un jeu que l'on appelle "développement". Ces règles du jeu m'encouragent à produire rapidement le code le plus ignoble possible, afin de trouver un maximum de bugs en phase de recette. Je serais ainsi félicité par mon manager et gratifié d'un joli bonus. Mon code sera couvert par des tests de régression, garantissant a minima que l'existant tombe en marche, mais mon intérêt est que chaque nouvelle fonctionnalité soit la plus sale et buguée possible. Ces règles du jeu encouragent les pompiers pyromanes.

Suis-je dans la caricature ? Bien entendu. De tels développeurs sont rares en sortie d'école. Mais ils peuvent le devenir, c'est là toute la magie des incitatifs (incentives en Anglais). Je voulais introduire mon propos en abordant le développement de logiciels sous l'angle de la théorie des jeux.

Psychologie du groupe

Un manager décide de recruter toute une équipe de juniors, en contractualisant leurs objectifs. Au départ, personne ne prête attention à ces indicateurs, ils ne génèrent ni récompense, ni sanction. Chacun fera du mieux qu'il peut, ou pas selon les jours. L'objectif ne deviendra visible qu'après quelques fiches de paie, comparées à la machine à café. Les joueurs prennent petit à petit connaissance des règles.

Prenons deux développeurs de cette équipe. Alice pratique le TDD et ne pousse jamais un code qui ne soit pas dûment testé. Bob modifie le code, vérifie que les tests préexistants passent, mais n'en rédigera de nouveaux qu'en cas de bug. En effet, si un bug recensé réapparaît, c'est une régression, donc un malus sur salaire. Bob est malin.

Arrive le passage en recette. Le code d'Alice ne pose que peu de problèmes. Celui de Bob, non testé, va générer de nombreux bugs. Subjectivement, le manager verra une Alice sereine, faisant ses heures normalement, sans stress. A contrario il observera que Bob ne compte pas ses heures pour débugger le projet, qu'il se défonce, râle et s'épuise pour tenir les délais. Plus objectivement, dans la feuille Excel du manager, Bob aura corrigé plus de bugs qu'Alice.

Bob est prudent, il sait qu'une régression signifie une retenue sur salaire. Il veille donc à tester ses corrections de bugs, en pratiquant un Defect Testing zélé. Tout l'y incite et c'est une bonne chose, mais n'aurait-il pas mieux valu que ces bugs n'aient jamais existé ?

En fin de mois, Bob aura un meilleur bonus qu'Alice. Pire : Bob aura une meilleure image auprès des managers : plus présent, plus impliqué, plus solidaire qu'Alice ! Chez Alice, la frustration monte lentement. Après plusieurs mois, Alice sera excédée. Elle sera engagée sur la pente du ressentiment et mènera les actions suivantes :

Tirer Bob vers le haut. Supposons Alice bienveillante. Elle va expliquer à Bob l'intérêt d'écrire un code de qualité. Or, même s'il est de bonne volonté, Bob n'a pas intérêt à changer. Ne plus générer de bugs, c'est baisser sa rémunération et perdre les faveurs du management ! Alice va donc commencer à ...
Haïr le management. Alice garde de bons liens avec Bob, voire essaye de s'en faire un allié. Elle tente de plaider sa cause auprès de la direction, mais la différence subjective d'image ne jouera pas en sa faveur. Elle passera pour la mauvaise élève qui tente de déplacer les poteaux de but, voire pour la collègue pétrie de jalousie. Bob n'a aucun intérêt à aller au delà de l'empathie passive. Alice finira par lui reprocher et en viendra à ...
Haïr Bob personnellement. Il ne mérite pas cet argent, il doit payer autrement. Bob ayant les faveurs de la direction, il est difficile de le dénigrer directement. Si elle n'a pas déjà démissionné, Alice baissera ses standards de qualité, afin de que Bob ne bénéficie plus de SON travail. Il veut travailler dans une soue ? Grand bien lui en fasse.

Pour les besoin de la narration supposons qu'Alice n'ait pas démissionné. Elle est devenue un Bob. Son comportement s'est d'abord ajusté par jalousie, pour emmerder Bob. Au fil des mois, sa rémunération augmentant avec l'approbation du management, Alice finira par oublier sa situation initiale. Elle est devenue une meilleure joueuse, considérant les règles en place.

5 ans plus tard, les référents techniques, les managers et les Lead Dev peuvent êtres des Alice ou des Bob, cela importe peu, de différents au départ ils sont devenus totalement interchangeables. Les objectifs peuvent même avoir disparu entre temps, la culture d'entreprise a intégré des pratiques qu'il sera très difficile de changer.

Dans le management des équipes comme dans la mise en orbite de satellites, un petit changement de trajectoire, indolore au départ, peut avoir des conséquences catastrophiques à l'arrivée.

Que faire ? Essai stratégique.

J'ai vécu ce qu'a subi Alice, mais je suis parti avant que ma haine du jeu ne se change en haine des joueurs. J'ai pris du recul et élaboré une réponse stratégique à ce problème.

Cette situation est une variante du Théorème du Singe, que l'on retrouve autant en entreprise qu'en politique ou dans les schémas d'usage des technologies. En faisant preuve d'empirisme organisateur, j'ai trouvé à ce jour trois issues pour quiconque refuse de finir comme Alice :

La contre-culture. C'est la voie majoritaire actuellement, avec le mouvement de l'artisanat du logiciel (software craftmanship). Devenir indépendant, travailler avec des clients "qui ont compris" (slogan de l'entreprise Arpinum), se fréquenter entre artisans comme sur Okiwi. L'idée est de créer un marché du code de qualité, cohabitant à côté du marché du code de masse.
L'entrisme dans le management. En France depuis Vichy, c'est le management qui amorce les changements, la base doit se contenter de suivre. Dans cette voie, le développeur accepte de jouer le jeu, pour mieux injecter son venin chez les grands comptes. Il entre par la porte de la formation, du conseil, du coaching, des RH, bref des fonctions transverses. L'objectif de cette stratégie est de changer les pratiques "par le haut" chez les grands comptes, en espérant les faire basculer et entraîner par mimétisme l'ensemble du marché.
Le rapport de forces. Dans ce scénario, Alice tient bon. Elle refuse de céder à la haine de Bob, cède au management sur l'accessoire, mais ne transige pas sur ce qui est fondamental : la qualité. Pour cela il faut une grande détermination et une bonne connaissance du Code du Travail. Le but est d'occuper, de durer, de convertir et de peser. C'est le modèle syndical. S'accrocher, tenir et finir par montrer que l'on a raison, à l'usure.

Je n'affirme pas la supériorité d'une stratégie par rapport à un autre. Je pense même que seul un mélange des trois permettra le basculement vers une culture de la qualité dans le logiciel. Mon propos est d'ouvrir des portes. Trop d'articles se contentent de constater les dégâts de la sous-qualité logicielle, en expliquent les causes et les remèdes sur un plan purement opérationnel et technique. Mon propos est de nature stratégique : Comment faire pour en finir avec les Louvois, les Chorus ou les ONP.

Cet article est le premier d'une tétralogie. Dans les mois qui viennent, je vais détailler chacune de ces pistes, mettant en évidence les avantages et les défauts de chacune. Plus important à mon sens, je souhaite relier chacune de ces stratégies avec des types de personnalités, afin d'orienter au mieux ceux qui veulent que les choses changent dans notre profession.

3 ans en ESN : Un bilan

Tue, 05 May 2020 00:00:00 +0000

J'ai passé 3 ans en ESN. Devenu indépendant, il est temps de faire le bilan. Les ESN sont-elles des affameurs ? Les clients sont-ils forcément des tortionnaires ? Le knout est-il utilisé pendant les périodes d’intercontrat ? Lisez et vous saurez.

Si ma vie ne vous intéresse pas, allez directement à la partie un bilan.

Comment en suis-je arrivé là ?

Tout a commencé par un beau matin morne, dans l’agglomération parisienne. J’achevais ma formation à l’École de Guerre Économique, sans avoir trouvé d’emploi dans le secteur de l'IE. J’en revins à mon premier et seul métier, le développement. Je recherchais tout sauf un emploi urbain, c’est alors qu’une annonce pour une mission en pré-embauche à Rodez s’est présentée. L’aubaine, malgré mes forts préjugés sur les ESN. Pour 6 mois de pré-embauche je m’en fichais. Quelques jours plus tard, je retrouvai Céline, manager chez Consort, sur le parking du Causse Comtal, dans la charmante commune de Bozouls. La mission a duré 6 mois, dans un environnement tellement beau qu’il a réveillé en moi le vieux démon des solitudes contadines. Il ne m’a plus quitté.

Canyon de Bozouls, Aveyron.

L’embauche n’a finalement pas eu lieu, mais l’excellent suivi de mission de Consort m’a fait accepter une seconde prestation, en attente de trouver un client final, pensais-je toujours à l’époque. Ce fut à Toulouse, chez EDF. Consort m’a aidé dans ma recherche de logement. Quitter Bozouls fut un crève-cœur, surtout pour le tristement célèbre ensemble du Mirail. Mon charmant voisin ruthénois m’avait surnommé « l’estrangé » (avec l’accent), à cause de mes origines charentaises. Qu’aurait-il pensé de mon nouveau domicile !

EDF fut une nouvelle surprise. J’avais troqué Céline contre Anthony, l’éditique contre la gestion de postes, les falaises pour les tours, mais cette mission fut très agréable. Franck H., Ingénieur SI, s’occupait de la partie fonctionnelle, Consort du management et de l’administratif et j’avais pour seul responsable technique … moi-même ! L’absence de pression quant aux délais et la grande liberté que le client me laissait quant aux solutions m’ont permis de livrer un logiciel de très bonne qualité en fin de mission. J’ai fait mes premiers pas dans la formation, avec l’encadrement d’un alternant.

Château de Launaguet, Haute-Garonne.

Après un peu plus d’un an, changement de décor. Je déménage à Launaguet, de l’autre côté de Toulouse, pour une mission chez Geosys, dans l’agronomie. L'équipe managériale change avec Kamil et Lucas, qui me suivront jusqu'au bout. Mon projet professionnel a déjà changé. EDF était une mission très plaisante, mais elle m’a révélé l’absurdité de me déplacer tous les jours au bureau, pour effectuer des tâches que je pourrais accomplir aussi bien à domicile. L’appel de la ruralité continuait de me hanter et le mariage approchant, je commence mes recherches d’une maison en Charente-Maritime, ma terre natale. Cette période a duré pendant plus d’un an, suivie par une seconde mission similaire, chez Techform, à Labège.

Un poste salarié en full-remote m’aurait convenu, mais le management français n'y est pas prêt. Les anglo-saxons ont toujours une décennie d'avance sur nous. Ne souhaitant pas attendre, cela m'a motivé à devenir indépendant, malgré ma phobie administrative. J'ai quitté Consort le 31 mars et je déménage en Charente-Maritime aussitôt le confinement terminé. J'espère pouvoir retravailler avec Consort, ou même avec certaines entreprises dans lesquelles je suis passé.

Un bilan

Le confinement m’a laissé le temps de réfléchir à ces 3 ans ½ de salariat. En apprenti bayésien, j’en profite pour me remémorer les préjugés que j’avais sur les ESN, afin de déplacer mes curseurs de Turing. Rendons-leur justice, elles ne sont pas l'incarnation de Satan sur la terre, mais des entreprises comme les autres, soumises aux mêmes impératifs de rentabilité.

Avertissement : biais

Every Single Cognitive Bias in One Infographic.

Cet article est fortement biaisé. Prenez-le comme un témoignage personnel. Il n’est adossé à aucune étude scientifique. Consort est une ESN de taille moyenne, « à taille humaine » comme on dit. Mes propos ne valent sûrement pas pour des ESN plus grosses. Je n’aborde pas non plus le sujet de la commande publique, très différent du monde de la prestation de services « au forfait ».

J’accuse parfois les entreprises pour lesquelles j’ai travaillé de « non-qualité ». C’est péjoratif, mais il ne faut pas le prendre comme une insulte. La non-qualité logicielle est le produit d’un système dans laquelle de nombreuses entreprises sont engluées inconsciemment. En bon corporatiste, je considère dans la plupart des cas mes pairs comme plus responsables que leur management. Haïssons le jeu, pas les joueurs.

Sous-rémunération : Relaxe

On accuse souvent les SSII de payer au lance-pierres. C’est en partie vrai, mais il ne s’agit pas d’autre chose que du prix de marché. Mettez vous à la place du management : vous n’avez pas d’expérience. Vous êtes fraîchement sorti d’une école dont la promotion est une boîte de chocolats : le recruteur ne sait pas sur quoi il va tomber. Le diplôme représente une capacité minimale, pas une garantie de compétence et les promos sortantes sont extrêmement disparates en termes de niveau. C’est d’ailleurs pour cela que les entreprises sont friandes d’alternants : ils ne coûtent presque rien et donnent à l’entreprise 2 ans pour savoir sur qui elle est tombée.

Illustration de l'effet Dunning-Kruger." class="figure-img img-fluid"/>

~~Illustration de l'effet Dunning-Kruger.~~

~~À cela s’ajoute l’effet Dunning-Kruger.~~ Il s'agit de l'ultracrépidarianisme, non de l'effet Dunning-Kruger. Beaucoup d’étudiants resteront coincés sur la montagne de la stupidité. Ils n’évolueront plus, se croyant déjà experts. Ils deviendront ce que l’on appelle des « Expert Beginners ».

Je ne suis pas un fanatique du libre-marché, mais dans le cas des juniors, le prix qu’il tend naturellement à produire est assez juste. Une fois votre compétence démontrée, vous pourrez renégocier votre salaire. Quelques astuces cependant :

Se renseigner sur le montant facturé au client, ce qui vous permet de connaître la marge que fait l’ESN. En négociation le déficit d'information fait le rapport de forces.
Lire la convention Syntec, surtout si vous êtes en forfait heure. Vous devez toucher au moins le plafond de la sécurité sociale. Vous trouverez des articles expliquant cela un peu partout.
Après quelques années, apprenez à vous situer parmi les professionnels de même niveau de compétence, sans fausse modestie ni orgueil déplacé. C’est très utile afin de trouver le salaire que vous pensez mériter, par rapport à la moyenne.

The Bell Curve. S'applique originellement au QI, mais peut aussi représenter la répartition en terme de compétence à un poste.

Vous pouvez aussi opter pour une autre stratégie : vous préparer à devenir un indépendant et voir votre employeur comme un futur client. Cependant je vous conseille d’attendre de ne plus être étiqueté « Junior » pour le faire. Personne ne fera confiance à un freelance junior, sauf dans les métiers de la création web.

A ceux qui objecteraient que les rémunérations à l’étranger sont meilleures, je répondrai deux choses :

Vérifiez le coût de la vie et la présence d’une sécurité sociale aussi englobante qu'en France. Préférer gagner plus, mais être moins couvert est une stratégie personnelle, ni meilleure, ni moins bonne qu’une autre.
Faites de l’open-source ou pair-programmez avec des américains ou des scandinaves. Le niveau moyen en sortie d'école m'a toujours paru beaucoup plus élevé qu'en France.

Pour toutes ces raisons, je pense que les ESN méritent une relaxe sur le chef d’inculpation « sous-rémunération », au moins pour les profils junior. Note : je suis parti aussitôt mon étiquette de junior perdue. J’ignore l’état des rémunérations pour les profils expérimentés ou Senior.

Pression psychologique : Disculpation

Le niveau de rémunération n'est qu'un avatar du rapport de forces. La capacité à choisir sa mission en est un autre.

Les ESN ne gagnent rien quand vous êtes en intercontrat. Nada. Quand vous n’êtes pas en mission ce sont elles qui jouent le rôle d’assurance chômage, en mieux (même salaire, formation, etc.). Il est logiquement dans leur intérêt de presser les prestataires afin qu’ils soient en mission, donc rentables à nouveau. C’est une question de survie pour elles. Sont-elles pour autant des monstres froids, recasant au chausse-pied leurs employés sur la première mission venue ? Ce n’est pas l’impression que j’ai eu. Bien au contraire.

J’ai fait plusieurs périodes d’intercontrat, allant de 2 jours à 2 semaines. Les plus courtes étaient purement utilitaires (déménagement pour changer de mission), les plus longues ressemblaient sensiblement à des vacances, sans avoir posé de congés. Que ce soit à l’agence ou en télétravail, je fus assez libre de faire ce que je voulais, m’autoformer en l’occurrence. Je n’ai subi aucune pression me contraignant à poser des congés ou des RTT. Peut-être est-ce différent ailleurs, mais Consort ne pratique pas ce genre de pressions injustes.

Je n'ai pas subi de pression à rester sur une mission décevante, en dehors des impératifs contractuels (les renouvellements de contrat sont trimestriels, il faut finir la période pour ne pas coûter des pénalités à votre ESN). Mon avis est biaisé, car la quasi-totalité des missions sur lesquelles j’ai été placé se sont révélées intéressantes. Quand l’une d’entre-elles m’a déçu, mon manager a organisé tout de suite une médiation avec le client, puis une sortie à la fin de la période contractuelle. Le marché est vaste, je ne vois pas l’intérêt qu’aurait une ESN à forcer ses collaborateurs sur des missions inadéquates.

La disculpation des ESN sur ce point est évidente, sauf si vous tombez sur une ESN ou un manager toxique.

Mercenariat : Coupable, et alors ?

« Marchands de viande », l'expression a le mérite d'être parlante.

Un surnom courant des ESN est « marchands de viande ». L’appellation est vulgaire, mais a le mérite d’être parlante. Un prestataire en ESN est comparable à un mercenaire.

Il n’y a rien de péjoratif dans ma bouche. Mercenaire est un métier comme un autre, surtout pour quelqu’un de rompu à la guerre économique. Si c’est souvent une obligation pour le junior, fraîchement sorti de son école, travailler en ESN devient un choix de carrière pour les profils plus expérimentés.

Le mercenariat n’interdit pas la loyauté, j’ai vu des prestataires et des managers entamer une relation de confiance sur le long terme avec leurs clients. Sur un marché concurrentiel comme les services en informatique, c’est un moyen de se démarquer. Il ne faut cependant pas perdre de vue que l’ESN obéit, comme toute entreprise, prioritairement à une logique de rentabilité. Les fanatiques de la gratuité, de l’open-source ou de l’esprit « rugbymen » des startups, ont rarement leur place en ESN.

Oui les ESN sont coupables d’être des mercenaires, et alors ? Ils proposent une offre bien différente des "armées régulières" que sont les clients finaux, qui conviendra à ceux qui souhaitent changer fréquemment de mission, tout en gardant la sécurité de l'emploi.

Qualité logicielle : Disculpation

Accuser les ESN pour le manque de qualité du code est un lieu commun chez les artisans du logiciel. « Code de SSII » est même devenu une insulte, servant surtout à désigner les abominations d’État, qui coûtent chaque année des millions d’Euros en maintenance et malfaçons (Louvois, ONP, etc.). Pour moi, les ESN ne sont pas responsables. Je n’ai aucune étude pour appuyer mes propos, juste un témoignage à prendre comme tel.

Il fallait qu’un bâton de chaise fût bien fait. C’était entendu. C’était un primat. Il ne fallait pas qu’il fût bien fait pour le salaire ou moyennant le salaire, il ne fallait pas qu’il fût bien fait pour le patron, ni pour les connaisseurs, ni pour les clients du patron, il fallait qu’il fût bien fait lui-même, en lui-même, pour lui-même, dans son être même.

Il se trouve que je suis têtu et particulièrement intransigeant sur la qualité de mon code. Certains clients comprenaient parfaitement cela et me faisaient confiance sur les délais. D’autres imposaient la cadence et se retrouvaient fort marris lorsque j’annonçais un retard sur la date de livraison, date qu’ils avaient souvent sorti de leur chapeau. Bien des collègues, prestataires ou non, résignés après des années dans de tels contextes, préféraient obtempérer et baissaient leurs standards de qualité. Ainsi naissait le fameux effet « boule de merde ».

L'effet boule de merde. La non-qualité ralentit les développements futurs. La pression sur les délais diminue encore la qualité. Cercle vicieux.

Je n’accuserai donc pas les ESN du déficit de qualité. Ce serait trop facile et parfaitement injuste. Certaines prestations m’ont permis de développer sereinement un code de grande qualité, d’autres furent un parcours du combattant où il fallait arracher au client des délais corrects. Certaines entreprises ont une culture de la qualité bien ancrée chez leurs salariés, ce qui force les prestataires à ôter leurs moufles avant d’entrer. D’autres ont des équipes parfaitement résignées à la non-qualité, le turnover des prestataires - libres de partir facilement, contrairement aux CDI - et l’hypothèse de la vitre brisée faisant le reste.

J’irai plus loin. Les ESN permettent aux développeurs soucieux de la qualité de quitter rapidement de contextes insatisfaisants. Les contrats sont fréquemment signés au trimestre. C’est assez de temps pour se montrer pédagogue avec un client. S'il ne comprend toujours pas l’intérêt de la qualité, il est temps de partir. Mon erreur de jeunesse fut sans doute d’avoir compris cet avantage trop tard.

Pour moi, les ESN ne méritent pas l'accusation d'encourager la non-qualité logicielle.

Indépendant : quelle différence

Je suis indépendant. En théorie je gagne (beaucoup) plus que lorsque j’étais prestataire. N’allons pas trop vite en besogne cependant. Il ne faut pas confondre recettes et bénéfices, surtout dans l’enfer fiscal qu’est la France.

L’ESN paye apparemment moins bien, mais elle vous décharge de très nombreux risques (chômage, maladie, litiges) ainsi que de fonctions coûteuses (formation, administratif, prospection, relation client). Être indépendant c’est choisir une grande liberté, mais passer également plus de temps sur autre chose que votre métier. C’est un choix ! Mes projets m’ont poussé à prendre ce chemin, mais il ne convient pas à tout le monde.

J’ai réalisé ce diagramme pour vous aider à y voir plus clair. Pléthore de chemins existent, tant que vous savez ce que vous pouvez et voulez faire. Je déconseille cependant formellement aux phobiques administratifs de devenir freelance, surtout avec des structures lourdes comme des EURL. Prenez dans tous les cas un bon comptable*.

J’espère que mes conseils d’ex-junior en ESN vous auront servi, j’ai essayé d’y mettre tout ce que le moi d’il y a quelques années aurait aimé savoir !

* Cette publicité pour mon comptable est purement gratuite.

EPSI

Wed, 01 Jan 2020 00:00:00 +0000

EPSI Bordeaux, Nantes, Arras, Montpellier, Toulouse, Rennes - Janvier 2020 - Présent - France entière

Formation d’étudiants niveau Bac+2 à Bac+5 en vue du titre Niveau 7 « Expert en informatique et systèmes d’information » en présentiel majoritaire. Entre 10h et 80h par module pour ~400hr/an

Maintenance applicative (Gestion de la dette technique, Refactoring, Anticorruption Layers)
Intégration continue (Teamcity, git, DIY CI)
Architectures matérielles et logicielles (Architecture, Design (anti)-Patterns)
Tests (fondamentaux, approfondissement, industrialisation)
Cahier des charges et expression du besoin (méthode EATDD/BDD)
Agilité et Lois du Développement (Extreme Programming, Textes fondamentaux de notre métier)
Web&API (HTTP, REST, APIs)
C#/.NET (initiation au langage et à TDD)

Pédagogie orientée pratique (4/5 du temps en atelier). Coding dojos, cas réels, exercices. Positionnement exploratoire : pratiques validées par la science, mais pas toujours répandues en entreprise.
Suivi technique pour la rédaction des mémoires de fin d’études. Participation aux jurys.

En dehors des cours spécifiquement dédiés à un langage, les étudiants sont libres de prendre le langage de leur choix, tant qu'il est orienté-objet : C#, PHP, Java, TypeScript, Python, etc.

L'IA va t-elle aussi tuer la démocratie ?

Sun, 17 Feb 2019 00:00:00 +0000

Le livre de Laurent Alexandre est semblable au Basilic de Roko, cette expérience de pensée mettant en scène une singularité bienveillante qui torturera tous ceux, même morts, qui n’ont pas aidé à sa venue. Comme le Basilic, l’ouvrage ne vaut pas grand-chose sur le plan logique, cumulant les hommes de paille, les approximations, les études non-sourcées, les prophéties et les arguments d’autorité. Comme le Basilic, l’ouvrage en dit long sur les peurs irrationnelles suscitées par l’IA, principalement au sein de l’élite cognitive, prétendument vaccinée contre l’obscurantisme par la rigueur scientifique. Enfin, comme le Basilic, l’ouvrage trouve son intérêt dans son contenu politique, presque métaphysique, à condition de le lire d’un œil dépassionné, capable d’extraire les avertissements pour notre temps, de la science-fiction omniprésente.

Le Dr Alexandre maîtrise bien son style habituel : faire peur pour susciter une réaction du public, puis des politiques à travers eux. Cette fois, le maire de Meaux, Jean-François Copé joue le rôle du politicien, plus mesuré, qui sait que la politique est l’art de louvoyer, non celui de renverser la table. Il adoucit l’alarmisme de la première partie, avec une idée derrière la tête : dompter la peur que suscite Laurent Alexandre pour annoncer un sauveur : l’Union Européenne. L’argumentation ne manque pas de contradictions et donne une impression de récupération politicienne. S’il pointe avec justesse le manque d’une vision à long terme incarnée dans un personnage fort et légitime, c’est pour mieux se réfugier chez les Commissaires Européens. La démocratie n’attendra pas l’IA pour mourir.

La conclusion partagée par les deux auteurs retient notre attention : c’est au politique de décider en matière de choix technologiques, à condition d’en posséder la capacité. Seules les puissances décident de leur avenir. Les auteurs ont raison de dire que le refus de tout progrès technique est intenable : nous serions vite colonisés et mis sous le joug de puissances plus avancées, qui nous imposeraient les technologies que nous refusions.

La France fait mine de vivre dans d’éternelles années 50, quand dans la Silicon Valley, le mouvement NRx envisage sérieusement une techno-dictature mécanique et barbare. Une classe cyborg dirigerait une armée d’esclaves biologiques sous l’œil d’une IA bienveillante. De son côté la Chine accole 1984 au Petit Livre Rouge, en créant un système de notation automatique des citoyens, conditionnant l’accès au logement, aux études, etc. Si nous perdons notre puissance, gage de notre indépendance, voici les Charybde et Scylla qui nous attendent.

Le livre cosigné par Laurent Alexandre et Jean-François Copé est loin de manquer d’intérêt, à condition de le prendre pour ce qu’il est : un pamphlet alarmiste, un coup de pied au derrière, destiné à sortir la France de sa torpeur, de sa non-puissance postchrétienne, de ses bons sentiments baveux et de son embourgeoisement sénile. Malgré son titre très mal choisi et ses deux parties assez inégales, il n’en reste pas moins une bonne lecture pour sensibiliser le public aux liens entre technologie, puissance et politique.

Return of the Obra Dinn

Wed, 06 Feb 2019 00:00:00 +0000

Second sans-faute de l’homme-orchestre Lucas Pope, après « Papers, please », Return of the Obra Dinn figure sans nul doute au palmarès vidéoludique de 2018. Ce jeu d’investigation nous fait incarner un agent d’assurance, chargé d’élucider à la Poirot le sort des 60 membres d’équipage de l’Obra Dinn, un navire marchand rentré au port en 1807, 4 ans après son départ, sans âme qui vive à bord. Ce thriller vidéoludique est une œuvre d’art où la musique, les graphismes minimalistes et le gameplay, peignent un tableau terrifiant du grand large et de ses créatures fantastiques. Terminer le jeu requiert une grande perspicacité, de la patience et du sens du détail. A jouer de nuit, à la lueur d’une bougie !

Plan IA 2021 : les régions, coordinateurs de l'innovation

Thu, 10 Jan 2019 00:00:00 +0000

7,6 milliards de dollars. C’est la somme investie par la Chine dans le secteur de l’Intelligence Artificielle (IA) en 2017, contre 5.8 milliards pour les États-Unis. Face à ces deux géants, la France qui pourtant ambitionne de devenir « leader de l’IA » et se sait en retard, n’investira que 1,5 milliards … sur 5 ans. Pire : au lieu de cibler, elle éparpille les crédits entre l’ensemble des collectivités qui ambitionnent d’être « capitale de l’IA ». Le diaphane ex-ministre du Numérique, Mounir Mahjoubi, ne semble pas pressé de trancher. Il est politiquement plus facile d’éparpiller les financements pour contenter tout le monde et surtout de s’assurer que personne ne soit jaloux de cet échec partagé.

Le 15 octobre 2018, la région Île-de-France a sorti un document très synthétique en 15 propositions, appelé « Plan IA 2021[1] ». Accompagné d’un communiqué sans doute rédigé par une machine, ce document présente l’ambition de la région : devenir la capitale de l’IA en Europe. Les franciliens ne partent pas les mains vides : le rapport est techniquement bon et adossé à des experts solides. Les problèmes sont d’ordre politique, avec un florilège des tares françaises les plus courantes.

Certaines propositions sont aussi simples que d’utilité publique : l’annuaire de l’IA qui encourage les partenariats entre entreprises locales, donc la création d’un tissu, par exemple. Citons également les aides à l’embauche de doctorants, ou les divers challenges et partenariats visant à promouvoir la discipline. D’autres sont plus discutables, comme la poursuite de l’aménagement du plateau de Saclay, désastre écologique coûteux (5,3 Md€ selon la Cour des Comptes[2]) quand Paris dispose d’une surface invraisemblable de bureaux vides à exploiter (800 000m² selon l’APUR[3]). Enfin, certaines sont de l’argent jeté en l’air, comme le « Lycée IA » ou les aides à l’innovation distribuées sans contrepartie pour la région ou le bien commun. Témoignage d’un manque de vision : deux mesures se contredisent. D’un côté la mutualisation des données (Big Data), vue comme le seul moyen d’entraîner efficacement les IA, au risque de dévoiler des données personnelles. De l’autre le développement du Transfer Learning, nouvelle manière d’entraîner l’IA avec des jeux de données plus restreints, bien plus compatible avec le cadre législatif européen (RGPD). Le Big Data, présenté comme « le sens de l’histoire » par certains techno-prophètes dont Laurent Alexandre n’est finalement qu’une méthode comme une autre pour créer des IA. Quand la législation tient bon, la Technique s’adapte toujours.

Plus largement ce plan IA pose la question du rôle politique des régions dans la conduite de l’innovation. Lorsqu’elles rassemblent et promeuvent les acteurs présents, de beaux succès sont possibles. Si elles s’entêtent à lancer des projets pharaoniques, elles échouent inévitablement, augmentant au passage la dette et l’imposition. La région doit être une communauté, non un promoteur si elle veut servir le bien commun.

[1] http://www.datapressepremium.com/rmdiff/2005659/IA2021.pdf

[2] https://www.ccomptes.fr/sites/default/files/EzPublish/09-projet-Paris-Saclay-Tome-1.pdf

[3] https://www.apur.org/sites/default/files/documents/parc_bureaux_parisien_potentiel_transformation.pdf

Techniques au travail, Technique dans la Cité : Le mur de l’atelier devait-il tomber ?

Sat, 25 Aug 2018 00:00:00 +0000

Texte de mon intervention orale du 25 août 2018 au Camp Maxime Real del Sarte à Parigny. Un lieu commun syndical voudrait que la séparation domicile/travail soit un acquis social, en permanence attaqué par le capitalisme vorace. C’est aller un peu vite aux conclusions. La thèse que je vais défendre est autre : il s’agit avant tout d’une affaire de Technique, non de politique.

Regardons l’histoire. Sans remonter à une Antiquité que je connais assez mal, au Moyen-Âge, à moins que vous soyez un marchand ou un transporteur, votre activité professionnelle se déroulait dans le cadre domestique. Le paysan travaillait à la ferme et l’artisan également sauf en cas de chantier. L’atelier ou le bureau étaient toujours à domicile. Vos collaborateurs étaient très souvent votre famille, l’épouse tenait la boutique et les comptes, les enfants étaient apprentis, chez leurs parents ou chez d’autres maîtres qui les logeaient. Le transport était lent et coûteux, la communication orale directe bien plus efficace.

La Renaissance connaît une première fissure dans le mur de l’atelier. L’apparition de l’horloge et de l’imprimerie séparent le cabinet du riche bourgeois, proche des lieux de pouvoir, de sa villa plus éloignée. En même temps, l’apparition du moulin à eau change les modes de production. L’Europe acquiert sa première source d’énergie pilotable centralisée (par opposition aux énergies fatales, vent par exemple et aux énergies décentralisées, comme le bétail). C’est désormais la disponibilité en ouvriers qualifiés qui limite la production. La Renaissance voit les maîtres-artisans se concentrer dans les manufactures, lieux optimisés pour une production à l’aide de machines-outils fonctionnant sur une source d’énergie puissante et centralisée.

Il faut attendre l’âge industriel pour voir le mur de l’atelier tomber à nouveau. Le gigantesque besoin de main d’œuvre et la faible vitesse des transports poussent les entreprises à loger leurs employés. A Nord c’était les corons dit la chanson, mais il n’était pas rare non plus que le capitaliste dorme à l’usine ou à la bourse. La seconde révolution industrielle voit l’apparition des banlieues pavillonnaires, véritables tissus adipeux des villes. La bagnole, si violemment dénoncée par André Gorz a permis l’éloignement géographique de la main d’œuvre.

Il faut attendre les années 2000 et Internet pour réunir à nouveau partiellement le domicile et le travail. Ces dernières années ont amplifié ce phénomène. Le cadre qui consulte ses mails dans le lit conjugal et le géant du web qui fait habiter ses salariés sur son lieu de travail participent du même phénomène. On notera aussi la mode des conciergeries d’entreprise, véritables auxiliaires de vie traitant le lavage, le repassage, la garderie, et j’en passe pour les salariés. Tout est fait pour maximiser le temps efficace du travailleur dans l’entreprise, souvent sous couvert de convivialité.

Notez que ces mutations ne sont pas une affaire de classe sociale ou de volonté politique. La caissière comme le trader sont touchés et même les patrons des GAFAM n’arrivent pas à complètement isoler leurs enfants de ces phénomènes. Les politiciens, tous pays confondus sont parfaitement désemparés face au phénomène. Instaurer un droit à la déconnexion est parfaitement vain face à l’ampleur de la déferlante. Dans une société technicienne, rien ne peut s’opposer à la marche de Technique, surtout pas le politique.

Toute technique modifie le rapport entre l’homme et le réel. Tout homme qui travaille produit des biens, des services ou des informations. Il est évident que toute technique modifiant la circulation des biens, des services ou des informations, modifiera très largement la société, mais plus particulièrement le rapport entre le domicile et le travail. Quand la transmission d’informations avec ses inconvénients est plus efficace que la rencontre physique avec le coût de transport, le domicile et le travail se séparent. Les technologies de l’information ont tendance à rapprocher le domicile du travail alors que les progrès dans les transports les éloignent.

Un autre phénomène modèle les rapports domicile/travail : la densité énergétique nécessaire au travail. Les concentrations manufacturières puis industrielles en sont des exemples : concentrez l’énergie, vous concentrez les lieux de travail de nombreux travailleurs en un point. Ce point n’est jamais le domicile d’un seul travailleur. Si les transports du moment ne permettent pas le déplacement pendulaire quotidien des salariés, les besoins de l’industrie les concentreront autour, voire dans l’usine. Les embouteillages chroniques de la Silicon Valley sont une des raisons qui poussent Apple et Google à loger leurs employés sur place.

Considérations sociales : est-ce souhaitable ?

Nous avons décrit ce phénomène comme étant cyclique et inéluctable si les technologies sont disponibles, étudions maintenant les avantages et les inconvénients de cette fusion entre domicile et travail, à l’heure actuelle.

Les principaux avantages de la chute du mur de l’atelier sont d’ordre écologiques : économies sur le trajet domicile-travail, diminution des surfaces de bureaux nécessaires et disparition des quartiers dortoirs. Le quartier redevient un lieu de vie, où les gens travaillent, habitent, commercent et se rencontrent. La souplesse dans son emploi du temps permet au travailleur d’avoir une activité associative et politique parallèle à son travail. La Cité renaît. Le télétravail permet des déplacements plus occasionnels du salarié à son lieu de travail, ce qui laisse sa chance à la ruralité. Un trajet quotidien de 2h est intolérable pour la plupart des salariés, il ne pose aucun problème pour une réunion hebdomadaire au siège de l’entreprise. Pour peu que la campagne s’équipe en télécommunications mobiles, elle attirera des cadres aisés capable de relancer l’économie locale. Enfin, la présence du travailleur à son domicile lui permet d’assumer un important travail fantôme, éducation des enfants, entretien du foyer, aide à la collectivité. Autant de tâches retirées au marché, rentrant donc à nouveau dans le champ du gratuit, ciment d’une communauté. Les familles éparpillées peuvent à nouveau faire souche si elles le souhaitent.

Cependant, ce tableau idyllique d’une France retrouvée ne doit pas occulter les inconvénients de l’absence de séparation entre domicile et travail. Le plus évident est la présence du patron dans la vie privée du salarié. Pire encore, la présence de votre moitié et de vos enfants en permanence sur votre lieu de travail. Des tyrans souvent contradictoires. Ensuite, le travail à domicile souffre de nombreux inconvénients pour qui travaille en équipe. Les télécommunications ne remplaceront jamais le contact humain direct, car elles réduisent bien souvent le langage à sa seule composante orale, occultant la gestuelle, le non-verbal, etc. L’absence de présence physique des collègues ne permet pas une véritable cohésion, autour de la machine à café ou de la pause de midi par exemple. La souplesse de l’emploi du temps a un revers : le manque de concentration. L’attention est sans cesse saisie par des taches multiples et le cerveau a besoin d’un temps non-négligeable pour se concentrer à nouveau après un changement de contexte. Le bureau permet plus facilement de se concentrer. Au domicile cela requiert une discipline monacale. Enfin, n’oublions pas le coût écologique des télécommunications, parfois bien plus élevé que les transports qu’elles remplacent. Le numérique vert est une vaste supercherie, le seul fonctionnement d’Internet est le premier poste de consommation d’électricité mondial. Ne parlons pas des ressources nécessaires à l’assemblage des ordinateurs, serveurs, routeurs et câbles.

A chaque métier son fonctionnement

Ma conclusion est d’abord un appel à ne pas être dogmatiques. Mes propositions vont être un appel aux professionnels mais aussi aux politiques.

Il est évident tout d’abord que certaines professions ne pourront jamais permettre une fusion domicile/travail, sauf à revenir aux heures les plus sombres de la Révolution Industrielle. C’est le cas pour tous les professionnels sur les chantiers, mais également dans l’industrie lourde. Les métallos, les mineurs de tungstène ou les constructeurs de missiles auront des difficultés à ramener le travail à la maison, vous en conviendrez. Cependant, cette concentration industrielle peut être réduite par un recours raisonné à une nébuleuse de sous-traitants plus petits et mieux répartis sur le territoire grâce aux technologies du transport et aux télécommunications. L’exemple du pôle aéronautique de Figeac doit servir de modèle.

Ma première proposition est de faire de la grande entreprise une affaire politique, soumis à un régime d’autorisation réservé aux seules industries de puissance. Les implications sociales, écologiques et géographiques de ces mastodontes sont trop lourdes pour être laissées à la seule loi du marché.

Pour toutes les autres entreprises, le choix doit être laissé aux salariés, sans régime incitatif dans aucun sens. Travailler chez soi ou à l’atelier doit être une liberté fondamentale et une responsabilité du professionnel. Chacun des modes de travail présente ses avantages et inconvénients, nous l’avons vu, seul le professionnel responsable sait quand rester à son domicile et quand se réunir dans les locaux de l’entreprise.

L’espace urbain doit être réorganisé pour faciliter ce choix. La mode des espaces de coworking doit se pérenniser afin de réduire la surface et donc l’empreinte écologique des bureaux. La rotation des salariés permet évidemment une réduction du nombre de bureaux utilisés en même temps. La numérisation des documents rend obsolète le bureau nominatif, servant également de zone de stockage. Ils sont amenés progressivement à être remplacés par des sièges minimaux, simples lieux de rencontre pour les parties prenantes de l’entreprise, plus que lieu de travail.

Au cœur des villes, il faut encourager les maires et cafetiers à recréer des espaces collectifs calmes et beaux : parcs, places ou bâtiments, équipés en WiFi et en tables, qui permettraient aux professionnels de recréer des communs, permettant autant de travailler que d’échanger et de prendre une pause. L’urbanisme des cubes de béton anonymes doit être démoli pour recréer des points de convergence.

Enfin, le raccordement des zones rurales à Internet doit être encouragé afin de redynamiser ces territoires. Des aides peuvent être accordées aux salariés pour l’installation d’un réseau haut-débit à leur domicile, par exemple. Il serait également temps d’ubériser les bus, pour créer un réseau de transports collectifs à la demande.

J’encourage chacun d’entre vous à porter ces propositions dans son entreprise ou dans sa mairie. Elles sont simples à mettre en œuvre, ne nécessitent que peu d’efforts des politiques et des patrons.

Technocritique : quels ouvrages pour débuter ?

Tue, 03 Jul 2018 00:00:00 +0000

Cela fait trois mois que l’on me demande une liste d’ouvrages technocritiques, ou du moins expliquant le phénomène technicien de manière abordable. Pour me faire excuser, cette liste prend la forme d’un article. Ce sera sans doute incomplet, aussi je me réserve le droit d’éditer cet article au fil de mes lectures.

Quel impact les techniques ont sur nos vies, notre civilisation et notre avenir ? En préambule, avant d’aborder des ouvrages plus conséquents et plus nuancés je conseillerai de lire le manifeste de Théodore Kaczynski, La Société Industrielle et son avenir. Le style agressif et très clair permet une entrée en matière en même temps qu’une claque initiale. Le bluff technologique de Jacques Ellul et Une société sans école d’Ivan Illich permettront de nuancer l’impact initial du manifeste de l’Unabomber sans entrer cependant dans les ouvrages les plus denses de ces deux auteurs. Enfin, Georges Bernanos et son essai, La France contre les robots vient clore cette initiation. Ces quelques ouvrages fondamentaux devraient vous permettre de faire un tour général de la question.

Pour plonger plus dans le détail, Comprendre les médias de Marshall McLuhan est une brique de base aux côtés de l’imposant Technique et Civilisation de Lewis Mumford. Je conseille de lire ces deux ouvrages par petites séquences entrecoupées de fictions, tant ils sont indigestes. Jacques Ellul et Bernard Charbonneau ont respectivement écrit La Technique ou l’enjeu du siècle et l’État, ouvrages fondateurs de toute la technocritique. A cela on peut ajouter L’obsolescence de l’homme de Günther Anders, un essai d’une noirceur déprimante. Le rapport Meadows, vulgarisé par Jean-Marc Jancovici permet de saisir l’importance de la question énergétique, aux côtés d’Énergie et Équité d’Ivan Illich.

Si les fondements spirituels de la Technique vous intéressent, L’Éthique protestante et l’esprit du capitalisme de Max Weber et Apocalypse du Progrès de Pierre de la Coste lieront la Technique à la question du libre-arbitre et de la grâce. Pour les catholiques, la lecture de deux encycliques est un passage obligé, même si parfois rébarbative, pour les repères qu’elles offrent : Rerum Novarum (Léon XIII) et Laudato Si (François). Les philosophes Fabrice Hadjadj et Hannah Arendt parlent sans cesse des rapports entre Technique et spiritualité, sans jamais leur dédier un ouvrage spécifique, il faut donc aller rechercher dans l’ensemble de leur œuvre une pensée pourtant riche et intéressante. Enfin, Sans feu ni lieu : signification biblique de la Grande Ville permet d’aborder le volet théologique complexe de l’ouvre ellulienne.

Enfin, à ceux qui cherchent des solutions pour demain, je ne saurai trop conseiller La Troisième Révolution de Bruno Lussato et Éloge du carburateur de Matthew Crawford, tous deux présentant l’artisanat comme une solution à la Technique. Certains écrits de l’Encyclopédie des Nuisances et de Pièces et Main d’œuvre sont d’un grand intérêt quand ils ne tombent pas dans l’attaque stérile du Capital.

Je n’ai pas abordé les fictions, qui m’emmèneraient trop loin de mon sujet. Peut-être l’occasion d’un nouvel article ! Bonne lecture.

Délit d’initié : le PDG d’Intel a vendu ses parts le 29 novembre

Tue, 09 Jan 2018 00:00:00 +0000

Tempête mondiale dans le monde numérique : Intel, géant mondial des microprocesseurs vient d’annoncer la découverte et la correction d’une faille présente depuis plus de 10 ans dans ses produits. 5 à 30% de réduction des performances sont annoncés après application du correctif. Cette affaire est sans doute connue depuis des mois chez Intel, à en juger par l’étrange transaction réalisée le 29 novembre par son PDG, Brian Krzanich. Le dirigeant a vendu l’intégralité de ses Stock-Options, ne gardant que le strict minimum. Coïncidence ou délit d’initié ? La presse française n’a pas encore évoqué l’affaire.

Pour plus de détails, nous vous proposons un article du site The Motley Fool, traduit par nos soins.

Le PDG d’Intel vient de vendre beaucoup d’actions

Ces transactions ne sont pas à prendre à la légère.

Le 29 novembre, Brian Krzanich, le PDG du géant des puces Intel (NASDAQ:INTC), a déclaré plusieurs transactions sur des actions Intel dans un Formulaire 4 déposé auprès de la SEC (Securities and Exchange Commission).

La plupart des transactions impliquaient l’exercice par Krzanich de stock-options, qui lui permettaient d’acheter des actions Intel à des prix nettement inférieurs à ceux du cours à l’heure actuelle, et leur revente immédiate sur le marché.

Il n’y a en soi rien de mal, ou même d’inhabituel, dans de telles transactions. Les dirigeants d’entreprise, et même certains employés, reçoivent souvent soit des stock-options et / ou des unités d’actions restreintes (UAR) dans le cadre de leurs régimes de rémunération, et les bénéficiaires de cette rémunération voudront tôt ou tard les convertir en liquidités.

En effet, comme expliqué ici, la vente faite par des initiés n’est pas toujours de nature à susciter l’inquiétude.

Toutefois, deux des transactions déclarées par Krzanich dans le formulaire 4 me semblent plus importantes que les exercices de stock-options ordinaires et les ventes subséquentes d’actions. Regardons de plus près.

Krzanich garde le strict minimum

Les statuts d’Intel imposent aux dirigeants et aux membres du conseil d’administration de détenir un certain nombre de titres de propriété à partir du moment où ils travaillent pour l’entreprise depuis cinq ans. Voici les montants basés sur le rang au sein de l’entreprise :

PDG	250,000
Directeur exécutif et président	150,000
Directeur financier	125,000
Vice-président exécutif	100,000
Vice-président senior	65,000
Vice-président administration	35,000
Autres vice-présidents et hauts responsables	5,000-10,000

Krzanich ayant été nommé PDG d’Intel en mai 2013, il devrait avoir 250 000 actions d’ici mai 2018, soit dans environ cinq mois. Il est donc intéressant de noter qu’avant de faire l’une des transactions qu’il a déclarées dans son dernier formulaire 4, il détenait 495 743 actions.

Après les exercices d’options et les ventes subséquentes (qui ont laissé sa position inchangée à 495 743 actions), Krzanich a ensuite réalisé deux autres transactions : une vente de 242 830 actions et une vente de 2 913 actions, chacune s’étant faite au prix moyen de 44,555 $.

Suite à ces deux transactions, Krzanich détient exactement 250 000 actions – soit le strict minimum qu’il doit détenir en tant que PDG.

Qu’est-ce que cela signifie ?

Krzanich a peut-être vendu ces 245 743 actions évaluées à près de 11 millions de dollars au moment des transactions pour payer une nouvelle maison ou acheter une œuvre d’art rare. Cependant, cette explication est trop simple et assez vague, notamment à la lumière de la grande manne qu’il a reçue lorsqu’il a exercé et vendu toutes ces options d’achat d’actions.

Au lieu de cela, étant donné que Krzanich semble avoir vendu toutes les actions qu’il pouvait sauf celles que les statuts d’Intel l’obligent à détenir, j’ai l’impression qu’il n’a pas une grande confiance dans le potentiel des actions Intel. Il est peut-être en cela influencé par un point de vue tiède (voire même négatif) des perspectives commerciales de l’entreprise à court et à moyen-terme.

Après tout, si on se souvient que le directeur financier d’Intel, Robert Swan, aurait déclaré dans une note rapportée par The Oregonian que la société a pour objectif d’augmenter sa capitalisation boursière à 300 milliards de dollars (avec des actions à plus de 60 dollars) d’ici 2021, n’aurait-il pas été plus sage pour Krzanich de garder ces actions, en collectant environ un quart de million de dollars par an en versements de dividendes, jusqu’à ce que chacune rapporte 16 dollars de plus, pour une valeur additionnelle de près de 4 millions de dollars ?

En effet, si on prend en compte l’affirmation qu’il a faite en février selon laquelle le marché potentiel d’Intel devrait atteindre les 220 milliards de dollars d’ici 2021, il semble étrange que Krzanich choisisse de ne garder que les actions que le règlement d’Intel lui impose.

Source : https://www.fool.com/investing/2017/12/19/intels-ceo-just-sold-a-lot-of-stock.aspx

Vers la fin (de la neutralité) d’Internet ?

Mon, 08 Jan 2018 00:00:00 +0000

Le 14 décembre 2017, la FCC[i] a officiellement mis fin à la neutralité du net. Hurlements du côté des « défenseurs des libertés » pro-neutralité, cris de joie du côté des « défenseurs des libertés » anti-neutralité. Cette décision n’est pourtant qu’un symptôme : la toile craque sous le poids des géants du web.

Le postier libre dans le monde libre

Revenons aux origines : Internet était un petit réseau reliant des utilisateurs de taille comparable, souvent à la fois clients[ii] et serveurs[iii]. Le réseau est conçu pour dissocier complètement la couche physique (transmission des informations) du transport (adressage, routage) et de l’information transmise. Pour prendre une image, n’importe quel colis bien adressé peut aller n’importe où en passant par un nombre indéterminé de bureaux de poste, qui communiquent entre eux comme bon leur semble (avion, barque, etc.). Implicitement, le postier n’avait pas le droit de discriminer le colis selon son origine, sa destination, son poids ou son contenu, par exemple en forçant les gros colis à prendre le bateau. Cette neutralité de fait d’Internet a permis son essor face aux réseaux concurrents.

Mon postier est surchargé

La neutralité de principe n’existait pas avant 2004, car elle allait de soi dans un réseau décentralisé. Quand la FCC adopte une déclaration sur la neutralité du net, il s’agissait déjà de sauver ce principe dans un réseau en cours de centralisation.

Les états, renseignement et justice en tête, ne pouvaient pas laisser cette immense cour de récréation sans surveillance. Avènement des pandémies informatiques, expansion du crime ou du simple délit contre le droit d’auteur : Internet devait être surveillé et censuré au besoin. Même les plus grands défenseurs de l’Internet Libre n’ont rien vu à redire. Certains hypocrites craignent une censure extra-légale par les opérateurs privés avec la fin de la neutralité. N’est-ce pas déjà le cas ? L’affaire Stormfront évoquée dans nos colonnes n’est pas autre chose, au nom de la lutte contre les discours de haine. Que dire des réseaux sociaux, véritables sous-réseaux d’Internet, qui censurent à tour de bras ?

Les nouveaux usages d’Internet ont polarisé le réseau : une multitude d’utilisateurs ne fournissant aucune ressource consommant des plateformes toujours plus fréquentées. Pour relier plusieurs villages autonomes, un réseau de petites routes fonctionne très bien. Autour d’une grande ville, vous devrez créer des autoroutes, des ponts, des métros. Internet fonctionne de la même manière. La polarisation crée de la centralisation, qui crée des coûts d’infrastructure.

L’infrastructure d’Internet est gérée par des transiteurs, dont les FAI[iv]. Ils doivent dimensionner la taille des tuyaux au volume qui y circule. Avec la neutralité du net, ils n’ont pas le droit de ralentir ou bloquer un flux sur la base de son contenu, de sa source ou de sa destination. Les transiteurs se voient obligés d’accepter le tout-venant et de dimensionner leurs infrastructures en conséquence. La neutralité du net a un effet pervers : elle permet un chantage des plateformes envers les transiteurs. Un exemple : YouTube est très apprécié des utilisateurs, qui se plaignent auprès de leur FAI à la moindre lenteur (« je paie pour ça »). Le FAI fait pression sur le transiteur pour augmenter la taille du tuyau le reliant à YouTube. Le transiteur doit réaliser des investissements assez lourds auquel YouTube refuse de participer, arguant que le tuyau bâti pour lui est neutre, donc théoriquement utile à tous. Les abonnements à la carte étant interdits par la neutralité du net, le coût est globalement répercuté sur l’utilisateur final.

Internet : une ressource

La fin de la neutralité du net va coûter cher aux plateformes comme YouTube ou Netflix, obligées de partager la facture de transit avec les utilisateurs qui les regardent. Pour la France, ce sera la seule conséquence de cette décision américaine, à moins que les autorités européennes ne décident d’en finir elles aussi avec la neutralité du net.

La fin de la neutralité est un symptôme de l’internet-marché : un portail de services à la carte. 5€/mois pour YouTube, 10€ pour Google, ne laissant pas de place en dehors des géants prêts à payer pour y figurer. L’utilisateur possèdera un simple terminal, sorte de smartphone verrouillé où l’on ajoute des applications.

L’avenir d’Internet est sombre, mais il est tout à fait probable qu’un autre réseau le remplace dans les années à venir. Il devra éviter les trois écueils qui tuent Internet : régulation des géants qui déstabilisent physiquement le réseau (GAFA, mais aussi FAI obèses), chiffrement intégral des échanges pour éviter les intermédiaires trop curieux et atténuation de la dichotomie client/serveur (P2P, réseau distribué).

La liberté du réseau a un prix, incompatible avec sa centralisation.

[i] Federal Communications Commission, l’autorité régulatrice des télécoms aux USA.

[ii] Le client demande une ressource sur le réseau

[iii] Le serveur fournit une ressource à la demande

[iv] Fournisseurs d’accès à Internet

Manhunt : Unabomber

Mon, 08 Jan 2018 00:00:00 +0000

Quand on traite de l’affaire Unabomber, la médiocrité n’est pas permise. Sauf à vouloir enterrer politiquement le personnage, il est impensable de peindre l’auteur de « La société industrielle et son avenir » sans évoquer les idées qu’il défend. La série a fait le choix d’occulter le fond au profit d’une analyse psychologique fade et improbable.

Enfant solitaire, adolescent trahi, jeune génie manipulé par le fumeux projet MKUltra : le cursus honorum du génie du mal transforme Kaczynski en cliché. Le procès final est une synthèse de pitrerie sans lien avec le réel où des protagonistes grotesques viennent ôter sa dignité à un personnage malmené. Le vrai Kaczynski doit enrager dans sa cellule.

Le personnage de Jim Fitzgerald sauve la série. Ce policier modèle à l’intuition perçante finira par coincer Unabomber en habitant le personnage. Obnubilé par l’affaire et par le Manifeste, il devra refuser d’être un rouage obéissant et penser différemment pour réussir. Il en paiera le prix : l’exclusion sociale.

La guerre des intelligences : recension

Tue, 14 Nov 2017 00:00:00 +0000

Le Dr Alexandre vient de publier un livre afin d’alerter la France endormie du danger de l’Intelligence Artificielle (IA). A l’heure où la Chine et les USA colonisent numériquement le monde, la France a-t-elle encore une chance de peser ? Si oui, faut-il obligatoirement signer un pacte faustien avec la Machine ? C’est à cette réflexion terrifiante mais passionnante que nous invite Laurent Alexandre.

Repenser l’intelligence

La thèse centrale du livre est la nouvelle définition de l’intelligence dans la société l’information. Les gigantesques masses de données nécessaires à quiconque prétend peser dans le monde d’aujourd’hui ne peuvent déjà plus être traitées par le cerveau humain seul. L’homme a besoin de béquilles algorithmiques pour s’y retrouver. L’intelligence de demain sera en réalité un « coefficient de complémentarité avec l’IA », afin que cette dernière reste un outil et ne devienne pas la maîtresse.

La France part désavantagée de la course au QI, déjà sprintée sans aucune barrière éthique par la Chine. Sans même parler d’eugénisme ou de transhumanisme, débats esquivés depuis des années dans l’Hexagone, nous traînons un vieux boulet : l’école à la française. Tiraillée entre le pédagogisme imbécile et une volonté rétrograde de retour aux Hussards Noirs, elle peine à former les élites de demain.

Les horreurs de la démocratie

Le trait extrêmement noir de la seconde partie du livre (2035-2060) laisse un sentiment de frustration : Laurent Alexandre explique à quel point la logique égalitariste, progressiste et démocratique, incontournable en France depuis 1789, nous happe dans les engrenages terrifiants du transhumanisme.

Comme pour la GPA aujourd’hui, les barrières éthiques de notre civilisation seront contournées à l’étranger. Les plus riches auront accès aux techniques d’amélioration du QI et aux augmentations physiques dans les 50 ans. Dans une France jalouse d’égalité, le différentiel entre les « augmentés » et les autres paraîtra insupportable dans l’opinion. Les augmentations prises en charge par la sécurité sociale seront la dernière promesse électorale à la mode.

Le scénario glacial du jeu Deus Ex : Human Revolution n’est pas loin, avec son cortège d’esclaves s’aliénant pour être employables et autres démiurges augmentés à l’extrême.

Futurologie et science-fiction

La troisième partie du livre (2060-2080) ambitionne d’éclairer des scénarios possibles. Sans doute le livre aurait-il pu s’achever ici. L’auteur relaie des scénarios déjà explorés : la Fondation d’Asimov, le Meilleur des Mondes d’Huxley, Computer God de Black Sabbath, Matrix ou bien Gattacca. Autant s’abreuver directement à la source.

L’évocation de ces scénarios par un influenceur comme Alexandre a tout de même son intérêt : il alerte sur leur possibilité, même marginale et invite à déterminer l’avenir de notre civilisation. Ellul l’avait écrit avant de mourir : dérouler le fil de la Technique en s’interdisant toute interrogation est périlleux car d’autres récupéreront le pouvoir de décider à notre place : milliardaires « philanthropes », dictateurs « éclairés » ou simplement l’opinion aveugle du troupeau. Entamons une réflexion technocritique donc politique. Comme le dit l’auteur pour conclure son ouvrage : « Nous aurons l’IA que nous méritons ».

Laurent Alexandre, La Guerre des intelligences
Intelligence Artificielle versus Intelligence Humaine

JC Lattès, 04/10/2017 20,90€ EAN : 9782709660846

Les « alternet » sont-ils viables ?

Wed, 20 Sep 2017 00:00:00 +0000

S’estimant privés de leur liberté d’expression, les groupes d’alt-right américains s’organisent face à la censure des géants de la Silicon Valley, très marqués à gauche. Posséder son propre serveur n’est aujourd’hui plus suffisant : les entreprises gérant l’infrastructure d’Internet n’hésitent pas à filtrer jusque dans les couches les plus basses du net : déconnexion de serveurs, retrait de noms de domaine, etc. Stormfront et The Daily Stormer, deux sites d’information de l’alt-right ont eu leur domaine retiré. Le site d’écoute musicale Spotify, le site de rencontre OkCupid et Paypal bannissent les prétendus « nazis » hors du web. Facebook et AirBnb ont supprimé les comptes liés à la manifestation de Charlottesville. Des centaines de comptes Facebook et Twitter sont suspendus chaque jour, y compris en France.

Pour l’instant, la censure extra-judiciaire ne concerne que les terroristes et « la haine », réelle ou soupçonnée. Les hypocrites défenseurs de la neutralité du net peuvent donc encore faire semblant de croire que cette dernière, morte depuis des années, existe toujours.

Une réussite très élitiste

Le réseau social Gab, fer de lance de la contestation, a proclamé le 10 août dernier la naissance de la « Free Speech Tech Alliance ». Cette alliance de professionnels doit permettre à terme la création d’un véritable « Alternet » : une partie d’Internet débarrassée de la Silicon Valley et de sa censure morale. Sur le papier, le projet sonne bien, mais sa viabilité est questionnable.

D’autres ont essayé avant eux, la réputation sulfureuse en moins. Depuis les années 90 les groupes crypto-anarchistes combattent l’Internet centralisé qui a accouché des fameux GAFA. Leur credo ? Les méthodes de chiffrement utilisées massivement doivent permettre la protection des échanges. Si vous envoyez un message chiffré, ce message est suspect pour d’éventuels attaquants, qui tenteront de le déchiffrer. Si vous chiffrez tout jusqu’à votre liste de courses, le volume de données sera trop important pour être traité.

Le succès de ces activistes est mitigé, malgré leur présence très importante dans le monde du logiciel libre. C’est une réussite technique très élitiste : l’essor des crypto-monnaies, des réseaux cachés, des darknets et des blockchains le prouve. Leurs seules réussites « grand public » sont la généralisation du protocole web chiffré HTTPS (car largement soutenu par la banque et le e-commerce) et la généralisation de messageries instantanées supportant le chiffrement de manière limitée (Telegram, Messenger …)

Difficile de réformer internet

Le projet de la Free Speech Tech Alliance est plus ambitieux. Une poignée de militants peut parfaitement communiquer à l’insu des services de renseignement, Daech et les fameux « hackers russes » de la campagne américaine l’ont prouvé. Pour toucher un public plus large, donc bien moins formé, il faut des outils plus conviviaux, ayant une certaine masse critique pour se faire connaître, mais surtout contrôlant toutes les couches du réseau.

Les réseaux informatiques fonctionnent comme un empilement de couches techniques (modèle OSI). La plus basse est la liaison physique, le signal électrique, lumineux, radio qui permet d’acheminer les données. La plus haute est constituée des programmes utilisant le réseau. Chaque couche est en principe indépendante des autres : on peut faire passer la même information par différents chemins sur le réseau, utilisant diverses technologies (fibre, ADSL, 4G) sans que cela change quoi que ce soit à l’arrivée.

Celui qui contrôle les couches les plus basses peut toujours censurer les couches au-dessus. Coupez le câble réseau, l’application la plus performante tombe. Un site Internet, un service de noms de domaine (DNS) se situent tous sur la dernière couche du réseau. Les géants du net contrôlent les couches inférieures : ils peuvent censurer à volonté.

Si l’alt-right a pour ambition de créer son propre safe-space sur Internet, elle devra bâtir toute une infrastructure. Elle doit donc posséder à minima : ses hébergeurs[1], ses bureaux d’enregistrement de noms de domaine[2], ses autorités de certification[3], ses fournisseurs d’accès à Internet[4] et ses transiteurs de contenu[5]. Tous ces acteurs doivent être utilisés par une certaine masse de sites lambda afin d’être indispensables à la vie d’Internet et ne pas se faire censurer. S’ils ne sont utilisés que par l’alt-right, ils seront rapidement mis au ban d’Internet. Chacun de ces acteurs nécessite des millions de dollars d’investissements, plusieurs années de dissimulation et des centaines de professionnels. L’alt-right a-t-elle les épaules de ses ambitions ?

Je n’ai évoqué ici que les cas des USA. Dans les pays où l’état se mêle de liberté d’expression comme en France, il faut aller bien plus loin, parfois contre la loi ce qui rend toute solution grand public complètement irréaliste. Dans notre pays, l’Internet libre ne sera toujours qu’un fantasme. Sauf changement politique radical, la liberté d’expression ne pourra qu’être le luxe d’une avant-garde de techniciens.

[1] Mettent des machines connectées 24/24 à disposition de clients : sites Internet ou logiciels divers.

[2] Permettent de retrouver une ressource à partir d’un nom simple à retenir : enzosandre.fr par exemple

[3] Délivrent des certificats permettant de s’assurer qu’un contenu est bien émis par qui de droit

[4] Connectent les particuliers au réseau Internet, ils sont la première ligne de la censure.

[5] Les « plombiers » du net : ils connectent tous les acteurs ci-dessus entre eux via de vastes réseaux régionaux

Se priver de machines pour un ascétisme moderne

Fri, 15 Sep 2017 00:00:00 +0000

Cet article est une recension du livre de l’abbé Philibert Rigault, Le Bon Travail, publié aux éditions de Chiré Jacques Ellul avait théorisé la non-puissance comme remède à la toute-puissance de la Technique sur nos vies. Cette solution est acceptable pour le protestant Ellul, elle ne saurait l’être pour un catholique : on se sanctifie en société et se couper du monde n’est aucunement de la charité. On attend encore une réponse catholique à la maladie technicienne. L’abbé Philibert Rigault dans son livre « Le Bon Travail », paru chez Chiré a le mérite de faire un premier pas dans ce sens.

« Tu gagneras ton pain à la sueur de ton front » : tout l’ouvrage est centré autour de cette injonction divine tirée du livre de la Genèse. L’abbé Rigault en tire le raisonnement suivant : Dieu est omnipotent, il pourrait créer de rien ce que les hommes font de leurs mains. S’Il veut que les hommes travaillent, il doit y avoir une raison. Dieu est amour : cela doit forcément être pour nous rapprocher de Lui.

La machine permet à l’homme de réaliser sans effort un travail. Si la machine est moralement neutre, son usage peut parfois aller contre l’injonction divine, la rendant mauvaise.

Pour l’auteur, la vision du travail a changé à l’âge industriel. Nous sommes passés d’une société de bâtisseurs de cathédrales se sanctifiant par le travail à une séparation du temps de travail et du temps d’élévation spirituelle. Ce dernier est fréquemment remplacé par des loisirs, rendus nécessaires par un labeur aliénant et éreintant. L’homme moderne trouve normal de s’abrutir tout le jour pour gagner sa croûte, puis d’employer le temps restant à en réparer les dégâts physiques et spirituels.

L’abbé Rigault appelle les fidèles à faire de la privation des machines un ascétisme moderne, s’ajoutant au jeûne et à la prière. Chaque fidèle est appelé à faire des sacrifices, à remplacer la machine par l’humain dans un aspect de sa vie : labourer à la main plutôt qu’au motoculteur, renoncer à la voiture pour les petits trajets, rencontrer les gens plutôt que de leur téléphoner ; bref recréer un dialogue avec le réel.

On regrettera cependant que ce petit opuscule brillant soit entaché de formules repoussoirs dont seule la Fraternité Saint-Pie-X a le secret. L’excès gâche un raisonnement pertinent : si votre enfant allume lui-même la lumière, il est mal élevé ; de mon temps le nourrisson jouait avec une vieille casserole et c’était mieux ainsi et tutti quanti.

Cet article est une recension du livre de l’abbé Philibert Rigaut, Le Bon Travail, publié aux éditions de Chiré

Le vice-amiral Coustillière se fiche des backdoors

Wed, 13 Sep 2017 00:00:00 +0000

La nomination du vice-amiral Coustillière comme DGSI[1] du MINDEF est mal passée auprès de certains experts français de la cybersécurité. En cause : une déclaration datant d’un an dans laquelle le gradé déclare que les principales failles de sécurité ne viennent pas des portes dérobées[2] introduites dans les logiciels de Microsoft et qu’il « se fout de ce débat ».

Au-delà de son manque de subtilité, l’Amiral n’a peut-être pas tort. Dans le cadre de l’OTAN, nos systèmes militaires n’ont en théorie rien à craindre des américains, nos « amis ». Il est même plus utile que tous les pays alliés travaillent sur une base logicielle commune.

Si la souveraineté de la France intéresse tant les experts de la cybersécurité française, qu’ils demandent d’abord la sortie de l’OTAN, ils n’en seront que moins hypocrites.

[1] Directeur général des systèmes d’information

[2] Failles de sécurité intentionnellement introduites par l’éditeur du logiciel, notamment sur demande de services de renseignement (NSA, CIA …)

Emprisonnons les mauvais développeurs

Mon, 28 Aug 2017 00:00:00 +0000

Dans toute profession, on peut voir le travailleur de deux manières. Soit on le considère comme un ouvrier, simple paire de bras reliée au cerveau de son chef. Soit on le considère comme un artisan, humain constitué d’un encéphale fonctionnel relié à une paire de bras. Ce débat peut paraître lointain, mais quand on pose cette question à propos d’une profession qui dirige le monde, elle prend une gravité certaine. La condamnation vendredi 25 août du développeur James Liang, à 40 mois de prison et 200 000€ d’amende pour son rôle dans l’affaire Volkswagen le montre.

Soit on considère le développeur comme un exécutant, donc irresponsable de ce que son donneur d’ordre lui demande.

Soit on le considère comme un artisan, responsable de ses actes et des effets des monstres qu’il créé.

Préférez-vous confier votre pacemaker, votre voiture autonome et votre centrale nucléaire à des professionnels du développement ou à des esclaves du capital ? Les premiers obéissent à des règles de l’art ainsi qu’à une éthique. Les seconds obéissent aveuglément à leur chef, qui n’y connaît rien et ne jure que par la rentabilité.

La conséquence directe de ce choix est le droit ou non des développeurs à se diriger eux-mêmes. Un ouvrier n’a aucune compétence propre, il est une paire de bras. Il n’a pas de devoirs, donc pas de droits non plus. Son rôle social est au mieux celui d’un syndiqué se battant pour des conditions de travail décentes.

Un artisan est un professionnel qui a le devoir de produire un travail bon et utile à la société, il doit donc exiger des droits allant dans ce sens. Le premier est celui d’être protégé par des normes que nul ne peut ignorer : les règles de l’art. Le second est celui d’être jugé en première instance par ses pairs, sur la base desdites normes. Le troisième est celui d’être défendu et conseillé par les maîtres de sa profession, y compris face à son donneur d’ordres lorsque l’éthique professionnelle est en jeu.

Si notre ami James Liang avait eu un corps de métier pour le défendre face aux exigences frauduleuses de ses supérieurs, aurait-il accepté de trafiquer les véhicules ? Isolé, le lanceur d’alertes risque le licenciement, la ruine et la prison. Les règles de l’art opposables protègent le professionnel, elles ne sont pas un carcan. Le but premier d’un corps de métier est la diffusion de celles-ci afin que nul ne puisse les ignorer.

Une société qui interdit les ordres professionnels n’a pas le droit de se plaindre des méfaits de travailleurs toxiques. Au pire malhonnêtes, au mieux sans défense face aux exigences de leur hiérarchie, ils sont la conséquence de la recherche du profit à tout prix. Les premiers doivent être jetés en prison, les seconds doivent être défendus et accompagnés.

Derrière la question de la responsabilité des travailleurs devant leurs actes, deux visions de la société s’opposent : la première bâillonne l’éthique au nom de la rentabilité, pavant la voix à une véritable voyoucratie du capital. La seconde jugule les pratiques néfastes au nom de l’éthique et du bien commun. Avènement de corporations servant le bien commun, ou triomphe du Capital. Aucune autre alternative n’existe.

La Puissance moderne

Tue, 08 Aug 2017 00:00:00 +0000

Recension d’un ouvrage de Raphaël Chauvancy – La Puissance moderne, aux éditions Apopsix

Retournons à une période clé de notre histoire : le règne de Louis XVI. La France est devenue la première puissance mondiale, grâce à une ambitieuse politique de guerre économique. Son armée de terre est la plus puissante d’Europe et les efforts de Vergennes ont porté leurs fruits sur mer : la flotte française pèse suffisamment pour infliger de sérieux revers à la perfide Albion, entamant son commerce sur la route des Indes. On le sait depuis Thucydide : on ne peut vaincre une puissance maritime que par la mer.

La diplomatie de la France est une merveilleuse machine à créer l’équilibre. Ayant bien compris qu’une puissance détruite cherche à se venger, la France réussit par de subtils jeux d’alliance à contenir les visées déraisonnables de ses voisins. Le royaume est allié à l’Espagne, par le sang, à la Hollande par anglophobie et à l’Autriche, par ruse.

A l’exception notable du redressement de la Royale, tous ces succès ne sont hélas que l’œuvre d’habiles et patients ministres. Louis XVI savait s’entourer pour compenser sa bonhommie. Les qualités qui font un admirable humain sont hélas des marqueurs de faiblesse pour un souverain, qui ne peut se permettre la gentillesse. La realpolitik française est morte avec Vergennes, quand le Bon Louis jugea pertinent de faire arbitrer la guerre civile en cours chez son allié Hollandais par l’Angleterre et la Prusse. Tout le jeu d’alliance français s’est effondré comme un parcours de dominos après cela. Ce fut le premier clou sur le cercueil de la dynastie Capétienne.

La France de Louis XVI était une cocotte-minute prête à exploser. La paix venait de la prospérité, car chacun avait d’excellentes raisons d’espérer mieux pour ses enfants. La Royale en pleine expansion était le formidable ascenseur social que l’armée de terre, sclérosée par la noblesse, avait cessé d’être. Le commerce florissant occupait les bourgeois, les détournant de leur jalousie envers les nobles. Le peuple était occupé à assimiler les techniques nouvelles, découvertes en France ou pillées aux Anglais par les agents de la guerre économique française. Hélas la prospérité était un exutoire, non une solution. La débâcle diplomatique provoquée par Louis XVI après la mort de Vergennes allait siffler la fin de la trêve intérieure.

La diplomatie équilibrée de la France, trop novatrice à l’époque où la puissance se comptait en hectares, n’avait pas valu au royaume que des amis. L’Europe n’aimait pas cette France médiatrice et pacificatrice, qui frustrait leurs envies de conquête. L’Angleterre avait échappé de peu à la perte de son statut de première puissance maritime. L’Europe fut trop heureuse de jeter de l’huile sur le feu pour embourber la France dans une révolte intérieure.

Toutes les composantes de la société française avaient des raisons de vouloir un changement radical. Louis XVI, grand conciliateur dans l’âme et montagne de bonté se trouvait bien seul à Versailles pour gérer une situation nécessitant de la poigne. Il fut incapable d’être le chef fort dont les français avaient besoin et le paya de sa vie. Telle une étoile en fin de vie, la France s’embrasa violemment, utilisant les réserves patiemment construites par la monarchie dans un grand éclat qui allait détruire l’Europe et laisser notre pays exsangue. La puissance accumulée par la France ne fut jamais autant visible que pendant sa chute.

Le livre de Raphaël Chauvancy explique à merveille les clés de la puissance française à l’aube de la Révolution. Très facile d’accès il n’en est pas moins très complet.

Google au secours des obèses de l'Internet

Tue, 01 Aug 2017 00:00:00 +0000

QUIC, SPDY et maintenant BBR. Les initiatives de Google sont louables, mais vaines. Pour prendre une image : C’est comme agrandir les portes pour laisser passer les obèses. Quand ils auront encore grossi ils ne passeront plus. De plus l’agrandissement des portes n’apporte rien aux gens bien-portants et peut même en inciter certains à se laisser aller puisqu’il est aussi facile de vivre obèse que sain.

La seule solution pérenne capable de sauver la neutralité du net et Internet en général, c’est de dégraisser.
Non, une page web de 1Mo n’est pas normale. En comparaison, les œuvres complètes de Shakespeare pèsent 100 fois moins !
Même une vue Google Maps ne dépasse pas 500ko.

Mais pour ça encore faudrait-il que les développeurs web se forment à ne plus être des porcs. Il faudrait d’abord qu’ils aient conscience d’être d’ignobles saligauds, ce qui pose la question de créer un label de qualité, voire de réglementer l’accès à la profession pour les pires d’entre eux.

Salopez le serveur avec votre code bancal c’est vous qui payez, mais ne refilez pas votre chtouille au client. Si votre site ne peut pas être chargé en moins de deux secondes par la mamie du Cantal sur son ADSL (1Mb/s) c’est de la merde. Point, fin du débat.

Les administrateurs réseau se cassent le cul depuis 20 ans à accélérer le web. La seule réponse des devs web a été d’alourdir encore les pages. C’est comme si les constructeurs automobiles avaient profité de la sobriété en carburant des nouveaux moteurs pour créer des bagnoles à 24 cylindres.Très responsable comme comportement.

Je n’épargne pas les graphistes, qui ont pris tellement de drogues ces dernières années qu’une page doit à minima avoir 3 carrousels et 2 images en 4K et 18 feuilles de style pour être considérée comme belle. Même Pieter Bruegel faisait moins chargé que vos bouses.

Lussato avait averti dans les années 80 : soit l’informatique s’amende, s’allège et privilégie les microsystèmes décentralisés, soit elle crèvera de sa centralisation et de son obésité, devenant le jouet exclusif de quelques multinationales. Et ce sera bien fait.

Simone Veil : Se protéger quand la censure frappe

Thu, 27 Jul 2017 00:00:00 +0000

Le 30 juin 2017, jour de la mort de Simone Veil, un visuel aux airs d’hommage est diffusé sur les réseaux sociaux. Il indique un site simoneveil.com, dénonçant très subtilement l’avortement de masse comme un abus non désiré par la défunte. Le groupe anti-avortement Les Survivants avait préparé son coup bien à l’avance puisque le nom de domaine a été réservé le 7 septembre 2016.

Un cadre légal bafoué

Quelques heures après sa publication, le site des Survivants a été suspendu par l’hébergeur OVH, sans qu’aucune décision de justice ne l’ait autorisé à faire cela. Un coup de fil de l’avocat de la famille a suffi pour que l’hébergeur se couche devant les menaces, au mépris de la loi. Ca n’est pas la première fois que les Survivants essuient un tel revers extra-légal : la plateforme de cagnotte HelloAsso avait ainsi supprimé la collecte de l’association quelques jours auparavant.

Le droit français fait d’un site Internet une publication comme un autre, soumise aux règles relatives à la liberté d’expression. La censure d’un contenu doit obligatoirement être prononcée par un juge, lors d’une procédure classique ou en référé. Dans cette affaire, aucun juge n’a été saisi, ni pour atteinte à l’image de la défunte, ni pour délit d’entrave à l’IVG, ni pour diffamation.

La presse, qui se targue d’être la gardienne de la liberté d’expression et de l’état de droit© s’est unanimement félicitée de cette décision. Certains sites insoupçonnables d’incompétence comme Numerama ont même sciemment menti. En jouant sur une nuance imperceptible par le profane, ils expliquent que le site n’a pas été censuré, mais que le nom de domaine simoneveil.com l’a été au motif qu’il utilise le nom et l’image de la défunte sans autorisation.

Cela est faux : le nom de domaine n’a pas été suspendu et fonctionne toujours. Quand l’internaute tente de se connecter le message signifie implicitement que l’hébergeur OVH a suspendu le site. Dans le cas contraire une erreur « Adresse Introuvable » aurait été affichée comme si vous saisissiez une adresse inexistante (exempledesiteinexistant.com par exemple). Les domaines .com appartiennent à l’ICANN, une autorité administrative américaine avec ses propres règles, qui n’a que faire des caprices d’un avocat parisien. Le motif n’est pas invalide pour autant : les Survivants pourront ultérieurement se voir retirer le domaine, après de nombreux mois et une longue procédure.

Se protéger face à la censure

En France, un hébergeur peut violer la liberté d’expression et être félicité par la caste journalistique. A cela s’ajoutent des lois à la légitimité discutable, comme le délit d’entrave numérique à l’IVG ou une vision très large de l’incitation à la haine. Il peut parfois être légitime de prendre des mesures contre la censure afin de poursuivre de combats nécessaires au bien commun.

Pour censurer, la justice dispose de quatre angles d’attaque : suspension du contenu chez l’hébergeur, suspension du nom de domaine, condamnation pénale du responsable éditorial et blocage administratif. Chacune de ces mesures obéit à un cadre légal bien précis, dont il suffit de sortir pour échapper à la loi.

Ce qui est arrivé aux Survivants est une suspension de contenu. Elle n’est possible qu’auprès d’un hébergeur français ou ayant des accords judiciaires avec la France. Si les Survivants décidaient d’héberger leur site aux U.S.A, au Cameroun ou en Corée du Nord, le site fonctionnerait de nouveau normalement.

La suspension de nom de domaine est plus complexe, mais on peut esquiver le problème. Si un nom de domaine est bloqué, un autre peut être facilement acheté, puis à nouveau un autre. Le site T411 a survécu des années comme cela grâce à la lenteur des procédures administratives. Exemple : simoneveil.net.

Un responsable éditorial ne peut être condamné que s’il est soumis à la loi française. L’utilisation de prête-noms étrangers est une solution abordable. Renseignez-vous impérativement auprès d’un avocat, la loi française a pris des mesures contre ces pratiques.

Le blocage administratif sert à l’état lorsqu’il a épuisé les autres recours. Il s’agit d’un blocage du site chez le FAI de l’internaute, au moment de la consultation. Il empêche la consultation par tous les internautes n’ayant pas de connaissances techniques étendues, ce qui est redoutable. TOR est le moyen le plus connu de contournement.

Au nom de bons sentiments ou d’idéologies moralisatrices, états et entreprises se permettent de châtier le mal-pensant, censurant à tour de bras. Il est important pour tout créateur de contenu de connaître des contre-mesures. A ceux qui pensent que la neutralité du net et la liberté d’expression tombent du ciel, nous répondons par la phrase de Maurras : « Les libertés ne s’octroient pas, elles se prennent ».

Avertissement : Ce court article ne saurait être exhaustif ou exact : prenez contact avec un spécialiste (technique et juridique) avant de mettre en œuvre de telles solutions.

Décoder les développeurs : enquête sur une profession à l'avant-garde

Sun, 18 Jun 2017 00:00:00 +0000

Celui qui raisonne comme au XXème siècle ne peut pas comprendre les développeurs. Ils sont les enfants terribles de la post-modernité, dans toutes ses contradictions : symboles du progrès technologique guidés par une conscience artisanale ; cols blancs à la mentalité ouvrière bien trempée ; libertaires contractualistes rêvant de communautés de métier ; geeks technophiles sévèrement critiques de la machine. Cette profession si particulière (que j’exerce moi-même avec beaucoup de fierté) annonce-t-elle un nouvel âge du travailleur qualifié ? Elle pourrait, comme le dit l’auteur « dessiner les contours d’organisations différentes, qui valorisent l’autonomie, la collaboration et l’énergie créative » et estomper le brouillard du taylorisme. Pour comprendre comment, il est incontournable de se pencher sur les caractéristiques du métier de développeur.

Le col ciel : un artisan de l’information

Le rôle d’un développeur est de programmer des logiciels en écrivant des instructions exécutées par la machine : le code. Le travail de développeur est hybride entre la profession intellectuelle et l’artisanat. L’auteur utilise l’expression « cols ciel », jonction entre les « cols bleus » et les « cols blancs » pour les désigner.

Comme tout artisan, le développeur ne peut pas être un individualiste. Même celui qui travaille seul a besoin de ses pairs. De nombreuses communautés en ligne ou physiques permettent au développeur de se former, de résoudre des problèmes rencontrés par d’autres ou de partager du code, en dehors de tout cadre marchand. La plupart des logiciels qui forment l’écosystème informatique aujourd’hui sont libres et aucun développeur ne pourrait travailler en autarcie sans programmer des années pour afficher la moindre image. En un sens, tout développeur est un héritier, devant tout à ses prédécesseurs.

Celui qui travaille en équipe est étroitement lié à ses coéquipiers, car tous modèlent en même temps le produit. Tout comme un orchestre, une équipe doit d’abord apprendre à travailler ensemble et le moindre changement humain est handicapant, le temps d’apprendre à travailler avec le nouveau venu. La taille d’une équipe n’indique en rien sa productivité : si un développeur peut faire un programme en neuf mois, neuf développeurs n’arriveront pas forcément à faire un programme en un mois, sauf s’ils ont appris à œuvrer ensemble.

Les rapports des développeurs avec les managers sont souvent conflictuels : les deux mondes ne se comprennent pas. Des pratiques comme la programmation en binôme, la revue de code mutuelle, le développement piloté par les tests et les entraînements sur du code improductif sont courantes dans les équipes de développement mais constituent de vraies hérésies pour un successeur de Taylor. Plus frustrant : les managers ont rarement le dernier mot face aux développeurs. Le code peut être soumis à des mesures objectives de qualité et de fonctionnalité. Comme le menuisier peut renvoyer son chef à la mesure de l’équerre et du fil à plomb, le développeur peut prouver la conformité du programme aux spécifications par des tests.

Chaque morceau de code produit doit pouvoir être relu et édité facilement, il en va de la productivité de l’équipe. « Laisse le code plus propre que tu ne l’as trouvé » est une des devises des développeurs. Etonnamment, ceux qui suivent cette règle finissent par l’intérioriser en une sorte de conscience ouvrière : le travail bien fait devient un primat.

Une profession en devenir

L’auteur dresse un portrait particulièrement élogieux des développeurs. Je dois dire que je m’y retrouve presque intégralement, me définissant moi-même comme « artisan-développeur ». Hélas l’auteur laisse dans l’ombre la majorité de la profession, les « analystes-programmeurs » et autres « ingénieurs développement ». L’analyste-programmeur pratique le même métier que le développeur, mais avec une mentalité différente : il privilégie un logiciel rapidement fonctionnel à un travail léché et préfère tout planifier à l’avance dans d’énormes cahiers des charges. Alors que le développeur n’a pas d’autre plan de carrière que de devenir un maître, l’analyste programmeur ne rêve que d’être un chef de projet, puis de suivre le parcours balisé du management technique d’entreprise. Les deux composantes de la profession se méprisent mutuellement : les développeurs voient les programmeurs comme des professionnels peu consciencieux, ceux-ci rétorquent en accusant les développeurs d’utopisme et de caprice d’enfant gâté. Il est intéressant de voir qu’à technique égale, la culture est déterminante dans l’usage que l’on en fait.

L’auteur a pris le parti de décrire une avant-garde artisanale de la profession, appelée sans nul doute à grandir et à s’organiser dans les prochaines années. Les déboires de monstres logiciels comme Louvois (logiciel de paiement des soldes de l’armée française) donnent des arguments de choc aux développeurs. Les sessions d’entraînement de type « coding dojo », le désormais célèbre Agile Tour et l’Ordre des Développeurs naissant sont autant de projets extrêmement stimulants, annonciateurs d’un nouvel âge du travailleur qualifié.

Références

Décoder les développeurs – Un livre sur une profession à l’avant-garde

Benjamin Tainturier – Préface d’Emmanuelle Duez – The Boson Project – Enquête sur une profession à l’avant-garde 138 pages – 19 € – G 56739

Livre gracieusement offert par l’éditeur Eyrolles.

Photo d’entête : atelier logiciel Arpinum

L'APRIL et son pacte du logiciel libre

Wed, 14 Jun 2017 00:00:00 +0000

C’est désormais une habitude : comme à chaque élection depuis 2007, l’association APRIL propose aux candidats de signer son Pacte du logiciel libre. Dans ce document minimaliste, les candidats s’engagent à ne pas voter de lois allant contre le logiciel libre s’ils sont élus. Se voulant le plus rassembleur possible, ce pacte ne rentre pas dans les querelles de licences ni dans les guerres de chapelles qui animent le monde du libre : son but est de sensibiliser les élus par un texte simple et compréhensible. L’initiative est prometteuse ; nous déplorons simplement les statistiques par parti, qui incitent les élus à parapher par discipline partisane plus que pour signifier des convictions personnelles. Nous regrettons également que les « coordinateurs » chargés de prendre contact avec les candidats soient trop souvent des militants de gauche, qui pratiquent un démarchage très sélectif, donnant l’illusion que seule leur famille politique s’intéresse au sujet du libre.

Dossier : l'Avenir de la production d'énergie

Wed, 10 May 2017 00:00:00 +0000

L’homme connaît l’existence du charbon et du pétrole depuis le néolithique. Il faut attendre l’âge industriel pour qu’il devienne une ressource énergétique nécessaire à l’industrie. Historiquement, le charbon a sauvé les forêts françaises d’un abattage méthodique, pour nourrir le Moloch industriel. Plus tard sont apparus le pétrole et le gaz, qui n’ont jamais diminué la part du charbon dans le mix énergétique mondial. Le nucléaire vint s’additionner.

Introduction

La part d’énergie dite renouvelable est ridicule. Le sens de l’histoire semble aller vers leur disparition, au profit de ressources de plus en plus denses en énergie. S’il y a un sens à l’histoire, l’avenir se trouve dans les centrales à fusion, non dans les panneaux solaires personnels.

Nous avons l’effronterie de ne pas croire que l’histoire ait un sens. Nous comptons bien dans ce dossier renvoyer dos à dos les écologistes et le cartel des énergéticiens. La centralisation de la production d’énergie n’est pas plus une fatalité que le retour à un passé fantasmé fait de silex entrechoqués et de feux d’excréments.

A l’âge des machines, celui qui produit l’énergie détient le pouvoir. Une production centralisée aux mains de l’État ou d’un cartel va inévitablement centraliser la société bien plus profondément que n’importe quelle idéologie politique. Pour libérer l’avenir, il est urgent de proposer des solutions réalistes de décentralisation. Les écologistes avec leur photovoltaïque ruineux, leur antinucléarisme de slogans et leur catastrophisme sur la fin imminente du pétrole représentent un épouvantail idéal. Il est impossible de bâtir l’avenir avec des bouffons aussi caricaturaux, ils ouvrent un boulevard aux industriels du nucléaire et aux escrocs de la fusion, ravis d’avoir en face d’eux d’aussi ridicules adversaires. Il est temps de bâtir un contre-discours sérieux sur l’énergie, laissant s’exprimer tous ceux qui refusent de participer à cette mascarade. Nous ne sommes pas obligés de choisir entre l’EPR et les éoliennes.

Entretien avec Jean-Pierre Petit

Ancien directeur de recherche du CNRS, M. Petit est un chercheur laissant derrière lui une fructueuse carrière dans l’astrophysique et la physique des plasmas. Très critique à l’égard de l’énergie nucléaire, M. Petit fut l’un des premiers à avertir de la gabegie que représente ITER.

Jean-Pierre Petit est également un vulgarisateur. Il est l’auteur de la série de bandes dessinées Anselme Lanturlu. Depuis quelques années, M. Petit diffuse des vidéos sur Internet, toujours dans le but d’expliquer la physique au plus grand nombre. Nous avons souhaité l’interroger sur sa vision du rapport entre l’homme et l’énergie.

Pensez-vous qu’il soit souhaitable pour les civilisations de disposer d’une énergie abondante ?

Les problèmes d’énergie, nous les avons évoqués dans notre dernier livre « OVNI, l’extraordinaire découverte », aux éditions Tredaniel. Dans l’histoire il y a toujours des changements qualitatifs profonds. Il y a eu l’invention de l’outil, qui a permis à l’homme de compléter son barrage biologique avec des griffes, des dents, des poings plus aiguisés et plus solides. Puis le feu, qui lui donnait accès à l’énergie que la nature abritait dans du bois, puis du charbon, des hydrocarbures. Enfin vint la vapeur qui transformait la chaleur en force colossale, capable de mouvoir des centaines de tonne d’acier sur des rails et d’actionner des machines outil, de travailler le fer et l’acier. En prime, derrière cette chimie et cette métallurgie, des armes de plus en plus perfectionnées, des canons, des blindages, des explosifs.

Et puis la conquête de tous les milieux. Se faufiler parmi les poissons, cette fois simplement pour mieux tuer. L’air, pour se déplacer, mais aussi pour porter des œuvres de mort. A la fin de la Seconde Guerre Mondiale, la course aux explosifs fait entrer l’homme dans le délire le plus total. Je crois que les êtres humains ne se rendent pas vraiment compte de ce que représente ce dernier saut. Ça n’est pas la capacité de destruction qui est en cause, c’est le dommage environnemental. Détruire, nous l’avons toujours fait. Des dizaines de millions de morts, des pays en ruine ? La belle affaire. On pensionne les veuves de guerre, on reconstruit, et un demi-siècle plus tard on ne voit plus les cicatrices de la dernière blessure. Un demi-siècle, qu’est-ce ? Deux générations d’êtres humains, sans plus.

Avec l’arme nucléaire il y a des produits de réaction, la radioactivité résiduelle, toutes ces saloperies dont les bombes nous gratifient et qui peuvent rendre des pays entiers, des continents, inhabitables pour des siècles, des dizaines de milliers d’années, voire plus. De terres rendues à ceux qui ont l’ADN solide, les scorpions par exemple.

Pour justifier cette industrie de guerre, on entreprend d’étendre les activités des réacteurs. Initialement conçus pour produire le plutonium des bombes, voilà qu’on en fait des générateurs d’électricité. La France joue un rôle de pointe et étend son parc.

Les années, les décennies passent. On découvre avec Tchernobyl et Fukushima la dangerosité folle de ces chaudières de l’enfer. Mais personne ne tire les leçons. Les réacteurs Japonais étaient installés au ras des flots. Ils le sont encore. L’inconscience, de nouveau, mène le bal.

Les Français ne réagissent pas encore dans ce domaine. Depuis des mois j’ai commencé à créer une suite de vidéos pour informer les gens. Les gens lisent de moins en moins. La vidéo, c’est le support de l’avenir. Je m’y suis mis. Allez regarder mon interview par Stéphane Allix à La science aux frontières du réel. Qu’un journaliste décide de m’interviewer intelligemment, c’est rare. C’est presque une première. Une seconde, en fait, car il y a eu le livre avec Bourret, issu d’une rencontre. Oui, je passe bien. Mais maintenant il n’est même plus besoin de journaliste, de plateau. On peut se débrouiller de manière autonome. Déjà 10 vidéos d’information scientifique sous le titre général JANUS.

Et l’énergie ? Ce sera la série suivante, avec très probablement un autre livre, avec Jean-Claude Bourret. Le titre ? « Nucléaire, suicide mode d’emploi ». Un livre urgent. Cela constituera une première réponse. S’il est un point sur lequel Mélenchon a raison, cent fois raison, c’est cette sortie urgente du nucléaire, avant qu’un réacteur de la région de Lyon n’explose, un jour de mistral, et que ceci rende toute la vallée du Rhône inhabitable.

Voyez-vous une piste intéressante pour la production d’énergie à grande échelle dans les recherches actuelles ?

Des solutions ? Nous en avons des milliers. Il faut dépenser de l’argent, créer des emplois, entreprendre des grands travaux.

Un exemple ? Couvrir les autoroutes de panneaux solaires thermiques, alimentant des turbines à gaz, elles même actionnant des alternateurs. Transformer tous les véhicules en hybrides, non pas seulement en les dotant de batteries, mais plutôt d’une perche rétractable qui leur permette sur les réseaux autoroutiers de puiser l’électricité, produite in situ, comme les auto-tamponneuses de nos enfances.

Il y a ça et des milliers, des millions d’autres solutions. A condition d’envisager, d’accepter de cesser d’être idiots, inconscients, irresponsables.

Ne pensez-vous pas que la centralisation soit un obstacle à la production d’énergie ?

On fait énormément de choses avec de l’énergie, surtout quand elle est renouvelable. On peut même, grâce à une production non centralisée, cesser d’être des esclaves pour redevenir des êtres humains, fiers de l’être et surtout fiers de pouvoir laisser à notre descendance un monde en meilleur état que celui dans lequel nous l’avions trouvé. Tant qu’à faire. On peut surtout arranger le mode de vie d’autres que nous avons délaissés et qui risquent de nous le faire payer très cher. Pourquoi ne deviendrions-nous pas optimistes, pour changer ?

Tout cela je vais l’écrire, le dire. En français et même dans les autres langues. Nous vivons à une époque où les citoyens prennent conscience qu’ils sont dirigés par des imbéciles. Il n’est pas trop tard, il est temps.

Jean-Pierre Petit,
Ancien directeur de recherche au CNRS

Richard Bulan : Crise de l’énergie ou énergie de la crise ?

Depuis le premier choc pétrolier, les discours alarmistes se répercutent sur les montagnes de la bien-pensance et de la vue court-termiste comme un écho dans une vallée trop encaissée.

Les matières énergétiques ne vont pas manquer dans des délais proches puisque même avec les politiques volontaristes actuelles, l’Agence Internationale de l’Energie prévoit une baisse des énergies fossiles de 82% en 1990 à 75% en 2040, ce qui est passablement ridicule. Ainsi, ce n’est pas une crise de l’offre, notamment avec l’arrivée de l’Iran qui a augmenté leur production de 500 000 barils/jours après la fin de l’embargo[1]. De plus, avec les prix de pétrole supérieur à 80 dollars de 2008 à 2015 ont permis l’industrialisation de processus complexes, engendrant des économies d’échelles, permettant l’augmentation de la production. La fracturation hydraulique connue depuis 1947 couplée aux forages horizontaux, développés eux depuis 1980, en ont profité permettant l’exploitation du pétrole de schiste. Ce dernier est particulièrement exploité par les Etats-Unis dont la production à augmenté de manière constante jusqu’à la chute des cours en 2015[2], et qui est repartie à la hausse au début de l’année 2017[3]. La production est maintenant est susceptible de passer de 200 000 à 500 000 barils/jours. De plus, les différents fonds souverains issus de pays pétrolier, comme l’Arabie Saoudite ou la Norvège ne prévoit pas une sortie de la consommation pétrolière, mais souhaite diversifier leur énergie pour limiter la pollution que cette consommation énergétique engendre.

L’offre de pétrole n’est pas à proprement parlé en crise, on est loin du pic pétrolier, avec le ralentissement de la croissance de la Chine, la volonté globale de limiter la volatilité du marché en lissant les cours avec les différents fonds souverains, ainsi que le développement de nouvelles techniques. Ainsi ce pic pourra arriver dans une dizaine d’année (vers 2030), avec une réduction drastique des ressources vers 2200 en ne prenant en compte que les réserves connues actuellement (certains états ayant une politique de secret concernant leurs réserves)[4].

Le passage à des techniques non pétrolière ou gazière va juste déplacer le problème sur des nouvelles matières. La France n’utilise que 51% d’énergie fossile dans son mix énergétique, si bien qu’elle est très dépendante de l’énergie nucléaire et donc du marché de l’uranium. Des questions similaires vont ainsi se poser pour l’ensemble des matière premières permettant la création d’énergie. Ainsi les énergies dites « renouvelables » utilisent également des minéraux comme les terres rares ou le cobalt, qui engendrera de nouvelles crises et de nouvelles périodes fastes dans une perspective « schumpeterienne ». La crise de l’énergie dispose en elle-même de l’énergie des crises futures …

Richard Bulan

[1] AFP, « L’Iran augmente sa production de 500 000 barils par jour », Les échos, 18 janvier 2016

[2] S. Cornot-Gandolphe, « La révolution des pétroles de Schiste aux Etats-Unis. Le test du business-model en cours », Notes de l’IFRI, janvier 2015

[3] E. Conesa, « Pétrole : l’Amérique prête à augmenter sa production », Les Echos, 29 décembre 2016

[4] B. Durand, « Pétrole, gaz et charbon : nature, mécanismes de formation, perspective d’avenir dans la transition énergétique », Association pour l’étude des pics pétrolier et gazier France, 31 mars 2017

Théophile Ducran-Lapoigne : La décentralisation énergétique, un projet au bénéfice du localisme ?

Le point de départ : la nécessité de réforme du système français

Au lancement de son programme nucléaire civil en 1958, les objectifs de la France étaient de se doter de capacités de production d’énergie à bas coût, en grande quantité, et sans que leur mise en place ni leur fonctionnement ne puisse opposer de quelconques menaces à l’indépendance nationale.
Cela fût fait. En 2017, la France est le pays d’Europe occidentale où l’électricité est la moins chère, et possède un parc nucléaire de 58 réacteurs répartis dans une quinzaine de centrales, ce qui en fait le pays le plus « nucléarisé » au monde par habitant.
Ainsi, ce système de grandes centrales, réparties inéquitablement sur le territoire, s’appuie sur un vaste réseau de transport et de distribution d’électricité.

Les activités de production, de transport, de distribution, et de fourniture d’électricité ont été déposées, à l’origine, entre les mains d’un « champion » national : Électricité de France.

Toutefois, ce système centralisé du « tout-nucléaire » présente aujourd’hui ses limites : du coût de démantèlement des centrales – qui ne sont, hélas, pas éternelles ! – à celui de gestion des déchets nucléaires, de nombreux obstacles s’accumulent au fil du temps.
En effet, pour des raisons propres à l’énergie nucléaire, mais aussi inhérentes à lui-même, le système français s’avère difficilement compatible avec les exigences écologiques contemporaines.
Par définition, un système centralisé offre un résultat puissant – et la France en sait quelque chose ! – mais génère inévitablement des pertes. A titre d’exemple, seule 1/3 de l’énergie brute produite par une centrale nucléaire est transformée en électricité – le reste étant évacué à travers les tours de refroidissement.
Compte tenu des exigences croissante d’économie d’énergie, un tel blocage apparaît comme de moins en moins acceptable.

De là, la décentralisation énergétique apparaît comme une solution viable sur les plans économique et écologique.
Cette notion peut se définir comme la distribution des capacités de production d’énergie par région, de manière à ce que les unités de production se trouvent géographiquement proches des consommateurs finaux, limitant ainsi l’utilisation du réseau de transport et offrant des capacités de résilience locale.

En effet, ce système comporte un certain nombre d’avantages qui lui permettraient de combler efficacement les lacunes de notre « tout nucléaire-centralisé » gaulois, et, sur le plan politique, d’encourager un retour au localisme.

Quel calendrier pour un nouveau système décentralisé ?

Il faut d’abord poser un premier axiome : le processus de transition énergétique, sera inévitablement accolé à la méthode de la décentralisation énergétique. Objectif et méthode s’accordent donc.

De plus, la transition énergétique vers des énergies vertes – ce que l’énergie nucléaire n’est pas, étant « décarbonnée » mais néanmoins productrice de déchets dangereux pour l’environnement et la santé – pourrait être achevée en France d’ici 2080.
La décentralisation énergétique n’est donc pas une solution sur-mesure applicable instantanément, mais résultera d’un processus national de long terme découlant de politiques publiques cohérentes.

Quels outils ?

Les énergies renouvelables portent un maître-mot : la résilience.
Par ce terme, il doit être entendu la résistance économique et humaine à l’absence de production d’énergie par une unité sur une courte période. En effet, la production d’énergie renouvelable dépend intégralement des conditions météorologiques du lieu où elles se trouvent.
Par conséquent, il n’est pas possible de prévoir avec certitude la production d’un parc solaire photovoltaïque, ni celle d’une ferme éolienne.
Cela suppose donc l’installation d’une variété de sources de production d’énergie, complémentaires entre elles.

La spécialisation au service de la variété

Chaque terre de France possède des caractéristiques naturelles différentes.
Ainsi, l’ensoleillement en Provence n’est pas le même qu’en Bretagne ; de même que l’Aquitaine, dont les côtes sont venteuses, n’a pas une activité géothermique aussi importante que celle du bassin parisien.
Ainsi, les capacités de production, mises sur pieds par région, devront répondre aux spécificités de l’écosystème local.

Un réseau de transport et de distribution renouvelé

Le système de production par région implique un renouvellement complet du système de transport et de distribution d’électricité. Jusqu’à présent, les lignes à haute-tension et très haute-tension partent des centrales, et sont connectées à des réseaux à basse-tension jusqu’à la fourniture finale. Ce système implique une logistique complexe, et des pertes notables, même s’il permet de « déplacer » l’électricité sur de longues distances.

Une production locale organisée selon une superposition des mailles territoriales

Une autre caractéristique majeure de la décentralisation énergétique est le régionalisme.
En effet, la production décentralisée ne doit pas devenir un ensemble de mini-systèmes centralisés, mais elle doit être organisée selon la superposition de mailles territoriales.
Ainsi, l’on pourrait aisément imaginer un système où 50% de la production serait mis à la charge des départements, et 25% à celle des régions et communes.
Cela étant, les communes bénéficieraient aussi du développement de la production domestique.

Le rôle de la production domestique

La production domestique, c’est-à-dire l’installation de capacité de production d’énergie directement au sein des foyers, devrait permettre de renforcer leur autonomie vis-à-vis des grands fournisseurs (EDF, Engie).
Cela étant, en subventionnant l’installation de telles capacités de production, les collectivités territoriales seraient en droit d’espérer un dopage de l’économie locale, notamment en matière d’emploi, voire de recherche.

Pour conclure, la question qui peut se poser est la suivante : dans quelle mesure la relocalisation des moyens de production d’énergie peut-elle avoir un impact sur le localisme politique ?

Toute activité commune étant source d’union, il est très probable que des populations, qui, au niveau local, se regroupent pour prendre en charge leur propres besoins en énergie, seront amenées à renforcer leur esprit de communauté, et, par extension, leur sentiment d’enracinement.
Reste à voir par quels biais politiques la décentralisation énergétique sera mise en place. Quoi qu’il en soit, il devrait être possible d’en tirer parti.

Théophile Ducran-Lapoigne

Conclusion : Quel avenir pour la production d’énergie ?

L’après-pétrole approche et il est temps de penser à son remplacement. Ecologistes et industriels doivent cesser leur autisme et entamer un vrai débat sur le mix énergétique de demain. Analyse d’un débat d’infirmes qui n’en finit plus.

Fission nucléaire : Rickover and over

Tous les réacteurs commerciaux au monde[1] héritent d’un réacteur originel, conçu par l’Amiral Rickover[2] pour propulser les sous-marins nucléaires américains. Il fut adapté pour la production d’énergie civile par Westinghouse, qui vendit la licence à Framatome (devenu Areva) et Mitsubishi. Les générations II (actuelle) et III (en cours de construction) ne sont rien d’autre que des améliorations. Or, le réacteur Rickover n’est pas conçu pour la production d‘énergie civile : il peut s’emballer (Three Miles Island, Fukushima) et produit une grande quantité de déchets radioactifs.

Pourquoi cette filière est-elle conservée ? Car la technologie est maîtrisée et amortie. Il existe pourtant des alternatives tout à fait crédibles, comme le Rubbiatron, le TRIGA ou les réacteurs à caloporteur hélium. Toutes sont reléguées en « génération IV ». Traduction : peut-être un jour, n’espérez rien.

Sur ce sujet, les écologistes sont les meilleurs ennemis de l’industrie. Ils font office d’épouvantail en rejetant complètement toute énergie nucléaire à l’heure où le charbon croît. Ils rendent inaudible toute critique fine du nucléaire, ce qui arrange bien l’industrie qui peut avancer sans garde-fou sérieux.

Fusion : Monomanie ITER

Pendant que ITER monopolise le budget de la recherche (19 milliards désormais), d’autres filières prometteuses sont anémiées par le manque de moyens. Malgré leurs budgets ridicules, la fusion aneutronique[3], la fusion par laser[4] ou les Z-machines pourraient donner des résultats avant qu’ITER n’ait abouti.

En plus d’être affreusement cher[5], ITER est une expérience dangereuse. Les Français seront rassurés d’apprendre que « La Commission européenne estime qu’en cas d’accident les rejets d’effluents radioactifs, sous quelque forme que ce soit, provenant d’ITER en France, ne seront jamais susceptibles d’entraîner, même en cas d’accident nucléaire, une contamination radioactive à l’extérieur des frontières françaises »[6]. En plus des matériaux radioactifs (dont le tritium, trop léger pour être confiné), ITER contient des matériaux aussi sains que du plomb, du lithium et du béryllium. Interrogez votre médecin, il vous expliquera.

De l’aveu même des physiciens, l’accident est probable : ITER est expérimental. Le dispositif contient de nombreux aimants supraconducteurs, capables d’exploser très violemment[7]. La plupart des savoirs mis en jeu seront testés pour la première fois à une telle échelle, avec tous les risques imprévisibles que cela occasionne.

Vive le charbon !

L’aveuglement idéologique des écologistes et les intérêts froids du cartel nucléaire embourbent tout débat. Le nucléaire actuel présente des défauts rédhibitoires, qui réclament un changement profond. Or tout débat sur l’avenir du nucléaire est bloqué par les écologistes, qui tiennent absolument à en sortir et par les industriels, trop satisfaits de vivre sur une technologie amortie. Les deux parties portent la responsabilité de l’accroissement du charbon.

Il est urgent de donner la parole aux physiciens et aux ingénieurs non-alignés sur ces questions, afin d’ouvrir un véritable débat national sur l’énergie de demain. Fusillons les clivages imbéciles et les intérêts à courte vue de l’Argent. En l’absence de souverain capable de trancher, c’est à la société civile d’arbitrer ces questions.

[1] Deux exceptions : les CANDU canadiens, qui ne sont pas vendus et les VVER/RBMK soviétiques, instables et dangereux.

[2] Le réacteur de Shippingport

[3] La réaction Bore-Hydrogène semble la plus prometteuse, elle permettrait même la fabrication de réacteurs à fusion domestiques dans un futur lointain.

[4] Le Laser Mégajoule du CEA est le plus connu, il est principalement destiné à tester les futures bombes thermonucléaires, mais devrait accueillir des expériences civiles de fusion.

[5] 19 milliards d’euros pour l’instant, hors fonctionnement. Déjà 4x le budget prévisionnel alors que la construction n’est pas terminée.

[6] Avis de la Commission Européenne 2012/C 166/01

[7] Le 27 mars 2007, un aimant supraconducteur a explosé au CERN près de Genève.

Spotlights

Mon, 01 May 2017 00:00:00 +0000

Spotlights SAS - Mai 2018 - Novembre 2019 - Paris

Spotlights est un journal innovant, participatif et géolocalisé qui s’adapte à l’usage du lecteur. Son fonctionnement est transparent et décentralisé grâce à l’usage de la blockchain.
J’ai réalisé l’intégralité du code en binôme avec un développeur junior. C#/ .NET fullstack. Blockchain et Event Sourcing sur toute la partie Data. CI/CD handmade (scripts Bash).

Spotlights est un média participatif décentralisé. Le site n'est hélas plus en ligne.

C'est autour d'une bande d'amis qu'a démarré le projet Spotlights en Mai 2018. De fil en aiguille, l'Atelier a été associé au projet et chargé d'en superviser le développement. Le projet était à la pointe des technologies du moment : blockchain, smart-maps, .NET Core. Le code était envisagé comme un squelette (ou tracer bullet en anglais), à savoir un code prévu pour avancer dans un environnement fonctionnel changeant ou incertain, permettant de lever itérativement les voiles de brouillard.

Le projet n'a pas trouvé son financement, le développement n'est pas arrivé à son terme, mais la méthode de développement utilisée a permis d'obtenir un code assez indépendant du monde extérieur, vieillissant très peu. La logique métier est découplée de l'infrastructure grâce à la Clean Architecture. Ainsi le projet peut rester en sommeil sans s'abîmer et ressortir un beau jour si des investisseurs se présentent.
Les principes du Clean Code, de DDD et TDD garantissent qu'un développeur reprennant le code pourra facilement se l'approprier, sans avoir besoin d'effectuer une obscure et coûteuse rétro-ingénierie.

Si Spotlights reprenait demain, l'Atelier serait bien évidemment de la partie.

Présidentielles 2017 : les programmes scientifiques et techniques analysés

Mon, 03 Apr 2017 00:00:00 +0000

Après avoir invité Emmanuel Macron pour discuter écologie, recherche, numérique ou santé, le magazine Sciences et Avenir a envoyé un questionnaire similaire aux autres candidats[1]. Nous avons lu et synthétisé l’ensemble de leurs réponses. Pour chaque thème nous avons retenu une idée particulièrement intéressante[2]. Les lecteurs souhaitant lire l’intégralité des entretiens les trouveront sur le site de Sciences et Avenir.

Énergie : Le clivage droite-gauche a survécu.

Avec l’immigration, l’écologie est sans nul doute le sujet principal de cette campagne présidentielle. Chaque candidat a son idée sur le mix énergétique : Mélenchon et Hamon veulent du 100% renouvelable. Dupont-Aignan souhaite lancer la 4^ème génération de réacteurs nucléaires (thorium). Fillon et Le Pen proposent un mix énergétique varié, excluant le charbon. Macron est dans le flou le plus total. Enfin, Jacques Cheminade semble être le dernier à croire en la fusion nucléaire à moyen-terme. Tous les candidats s’accordent sur la nécessité de financer la rénovation thermique des bâtiments pour économiser l’énergie.

Marine Le Pen semble la seule à proposer l’utilisation durable de la biomasse pour le chauffage.

Des transports peu ambitieux

Sur les transports, la gauche est très peu ambitieuse : elle veut la fin du diesel, point final. La volonté de récupérer l’électorat écologiste y est sans doute pour beaucoup. Il faut aller chez Fillon, Dupont-Aignan, Le Pen et Asselineau pour trouver une volonté de développer l’hydrogène et l’électrique, avec chez ces trois derniers, la création de champions français. Jacques Cheminade lie transport et économie dans un ambitieux projet ferroviaire.

Nicolas Dupont-Aignan est le seul à exiger la sobriété énergétique des véhicules thermiques. Il souhaite atteindre normativement une limite de 3L/100km, techniquement réaliste.

Economie : penser local, agir global

Réjouissons-nous : dans les discours l’heure est à la décentralisation ! Jean-Luc Mélenchon souhaite « plus d’état », mais déconcentré. Marine Le Pen rêve d’un souverainisme enraciné. Nicolas Dupont-Aignan et François Asselineau veulent des circuits courts et une production alimentaire intégralement locale. Les deux candidats PS sont dans un flou total à base de « circuits courts », « démocratie locale » et autres « décisions populaires ». François Fillon remporte la palme avec son concept d’agriculture locale et intensive (oui !). Seuls Nathalie Arthaud et Jacques Cheminade assument une doctrine centralisatrice. Tous les autres ont l’air de croire que la République peut décentraliser.

Jacques Cheminade souhaite une France des villes intermédiaires, redynamisées par le rail moyenne vitesse. Il propose la réouverture de très nombreuses lignes de province, afin de sortir du schéma en étoile actuel.

La France des robots

Tous font l’éloge de l’intelligence artificielle et du travail des robots. Seul Benoît Hamon souhaite taxer la valeur ajoutée produite par les machines. Sauf deux candidats, tous promettent une cyberdéfense nationale et la souveraineté numérique. Nathalie Arthaud refuse tout cela : ce sont des « ruses capitalistes » (sic). François Fillon lui, rêve d’une cyberdéfense européenne.

Soulignons la clairvoyance de Jacques Cheminade sur ces questions : pour lui la sécurité et la souveraineté sont une affaire de résilience, donc de décentralisation. Il souhaite préserver la vie privée des citoyens face à l’état et défend le logiciel libre, seule garantie d’indépendance.

Santé publique : clivage entre humanistes et techniciens.

Les questions de santé font apparaître de bien curieux clivages : Asselineau et Arthaud défendent une automatisation massive des soins. Mélenchon, Macron et Le Pen refusent cette déshumanisation. Les autres candidats restent flous et proposent de mettre de l’argent partout. Le principe de précaution est défendu par Mélenchon, Le Pen, Hamon et Asselineau. Fillon et Cheminade y sont opposés. Dupont-Aignan reste sceptique. Macron n’en parle pas.

Plutôt qu’un principe de précaution abstrait, Nathalie Arthaud souhaite une pénalisation dissuasive des scandales sanitaires, qui obligerait les cadres à la prudence en matière d’innovation.

Recherche : priorité nationale, comme le reste

Il faut de l’argent pour les chercheurs et les PME innovantes, tous sont d’accord ! Quelques légers clivages apparaissent autour du Crédit impôt recherche et de l’autonomie des universités, rien de grave.

L’absence de projet est plus préoccupante. Seul Jacques Cheminade fixe clairement un objectif avec son ambitieux programme spatial. Les autres candidats se contentent de promettre plus d’argent à tous, une méthode électoralement éprouvée.

Égalité, égalité !

Tous les candidats masculins ont promis une grande loi sur la parité homme/femme. Les plus libéraux comme Dupont-Aignan et Asselineau proposent des actions de communication et de labellisation des entreprises vertueuses. Mélenchon, Hamon, Macron et Fillon sont pour une parité stricte dans le public. Jacques Cheminade prône « L’Éducation du Peuple » (sic) et la camarade Arthaud assure que ça ira mieux avec un bon régime communiste.

Seule Marine Le Pen est défavorable à la stricte parité homme/femme. Elle préfère s’attaquer aux éventuels blocages point par point.

[1] Philippe Poutou n’a pas répondu et Jean Lassalle trop tard pour figurer dans cet article.

[2] Sans forcément être d’accord avec le reste du programme.

La sécurité dans l'histoire

Fri, 17 Feb 2017 00:00:00 +0000

L’évolution de la notion de sécurité reflète bien la mentalité de chaque ère. L’Antiquité et le Moyen-Âge ne concevaient pas la sécurité physique. Tout homme savait qu’il pouvait mourir à tout moment, terrassé par quelque lame ou maladie. Il faut attendre l’ère classique pour que l’omniprésence de la mort recule, en grande partie grâce à la technique. La sécurité physique commence à faire sens, mais d’une manière subjective. La sécurité subjective est l’extension physique de la sécurité spirituelle, rendue concevable par des temps moins rudes.

Securitas (latin) : Exemption de soucis, tranquillité de l’âme. Quiétude devant la mort. Insouciance, indifférence.

Sécurité (17ème – 1935) : Confiance, tranquillité d’esprit qui résulte de l’opinion, bien ou mal fondée, qu’on n’a pas à craindre de danger.

Sécurité (sens moderne) : Situation dans laquelle quelqu’un, quelque chose n’est exposé à aucun danger, à aucun risque.

Il faut attendre la Seconde Guerre Mondiale pour que le sens de la sécurité évolue à nouveau. Elle est au sens moderne, l’absence mesurée de dangers. Une fois pesée et quantifiée, le technicien consciencieux pourra s’atteler à la renforcer, car tout risque est un crime de lèse-efficacité. De norme acceptée, le risque devient une insupportable incertitude qui doit être traquée au nom de la rationalité. L’insécurité devient un cancer qui ronge l’horlogerie industrielle, l’interstice dans lequel peut se loger la pierre qui fera défaillir l’engrenage.

L’amour de l’homme moderne passe du prochain à la machine stérile qu’il a enfanté. Conséquence de ce narcissisme : le prochain devient une source d’insécurité qu’il faut absolument juguler.
La société industrielle ne s’arrête pas aux portes de l’usine. Toute institution traditionnelle, inefficace car l’efficacité n’était pas son but, sera remplacée par un rouage calibré plus efficace. Partout ou abonde l’efficacité, disparaît le souci de l’humain. La société sécuritaire est l’enfant naturel du transfert du sacré vers la Technique. De prochain à aimer, l’homme devient une rature à gommer ou à changer en robot. Tu es pierre et de cette pierre je sculpterai un rouage. Voici le sens de la sécurité objective moderne.

Principe de précaution, boulet économique ?

Tue, 24 Jan 2017 00:00:00 +0000

Dans le programme de François Fillon, en page Agriculture, on peut lire qu’il souhaite « Supprimer de notre Constitution un principe de précaution dévoyé et arbitraire. ». Il invoque la perte de compétitivité causée par ce principe et l’inflation normative qui en résulte.

La présence de cette proposition en page agriculture n’est pas innocente : le principe de précaution a déjà permis de bloquer la progression des OGM, ainsi que de nombreux intrants agricoles suspectés d’être dangereux pour les populations ou les pollinisateurs. Les partisans d’une agriculture intensive, agrochimistes et FNSEA en tête, réclament depuis des années l’abrogation de ce principe. François Fillon ne fait que la reprendre dans son programme.

Le principe de précaution constitutionnalise la primauté de l’environnement sur l’économie. Une partie des libéraux hurle contre cela, oubliant sans doute que sans environnement vivable, il n’y a pas d’hommes, donc pas d’économie[1]. Les règlementations environnementales sont des politiques de gestion du risque technicien. Aussi imparfaites qu’elles soient, elles réduisent le risque que les générations futures soient sacrifiées sur l’autel du bénéfice immédiat, ou du fameux automatisme technicien identifié par Ellul[2].

L’actuel principe de précaution est largement perfectible et les critiques de M. Fillon sont en grande partie recevables, bien que souvent hypocrites : Monsieur Fillon n’est-il pas pour l’Union Européenne, qui ne cesse de normaliser, sur ce sujet comme sur d’autres[3] ? Même si le candidat Fillon souhaitait sortir de l’UE, il lui resterait à affronter l’inertie du système républicain. Le principe de précaution, dans un état centralisé, ne peut pas donner autre chose qu’un monstre juridique tant les cas particuliers à chaque localité sont nombreux.

sciences-citoyennes.png

Autre conséquence funeste de la démocratie : Sur des sujets aussi clivants que les OGM, le parlementaire se retrouve pris en étau entre le lobbyiste et l’opinion publique. Le scientifique n’est pas non plus dans une position confortable : ses crédits dépendent fortement du pouvoir politique ou du monde de la grande entreprise, pendant que l’université française est contrôlée idéologiquement par de véritables ayatollahs de la surprotection contre les « ravages de la techno-science ». Les extrêmes sont hélas bien plus médiatiques que les nuances constructives.

Préserver l’héritage en attendant l’héritier. Le principe de précaution, malgré ses imperfections colle bien à notre objectif. Il est un bon palliatif à l’absence d’un souverain responsable, de par les garde-fous qu’il met à l’hybris technicienne et au capital sans fin. Ses défauts majeurs, que nous avons détaillés dans cet article, sont en grande partie issus de notre appartenance à l’UE et à une république incapable de donner du pouvoir aux localités. Rien de neuf sous le soleil.

Historique du principe de précaution

François Fillon ne prend pas la peine de définir le « principe de précaution », pourtant largement polymorphe, dans son programme. Retour sur l’histoire d’une notion controversée.

Le principe de précaution est né dans les années 70, en Allemagne. Il est fortement inspiré par la philosophie d’Heidegger. Il entre dans le champ politique pour la première fois lors du Sommet de la Terre de 1992 à Rio ou il est formulé comme suit :
« En cas de risque de dommages graves ou irréversibles, l’absence de certitude scientifique absolue ne doit pas servir de prétexte pour remettre à plus tard l’adoption de mesures effectives visant à prévenir la dégradation de l’environnement. ».
Le principe de précaution est repris presque à l’identique en France dans la loi Barnier de 1995 en y ajoutant une condition de « coût économique acceptable ».

Le principe de précaution qu’évoque M. Fillon est celui intégré à la Constitution en 2004. Il est défini dans la Charte de l’Environnement et son but est d’empêcher des dommages potentiellement irréversibles, causés par une technique dont les effets ne sont pas encore bien connus. Le principe de précaution des années 1990 était avant tout une déclaration de principe assez inoffensive, aux conditions d’applications très floues. Le même principe, en 2004, désigne la primauté constitutionnelle de l’environnement sur l’économie.

[1] « économiser signifie d’abord et avant tout prendre soin. » rappelle Bernard Stiegler dans son manifeste Ars Industrialis

[2] L’automatisme peut être résumé par « Si on peut, on veut ». pour Ellul, il est caractéristique d’une société technicienne.

[3] Il accuse les parlementaires français de « surtransposer ». Quoi de plus normal lorsqu’il s’agit d’appliquer localement une directive générale et vague ?

Lire ou relire : Théodore Kaczynski

Mon, 09 Jan 2017 00:00:00 +0000

Théodore Kaczynski, plus connu sous le pseudonyme d’Unabomber, est un penseur néoluddite et un terroriste américain. Il est l’auteur du manifeste La Société Industrielle et son Avenir, synthèse de penseurs comme Jacques Ellul ou Georges Bernanos. Il défend la destruction complète de la société industrielle au motif qu’elle asservit inéluctablement l’homme.

J’ai souhaité écrire cet article suite à la relecture des œuvres d’Unabomber. Il est l’auteur qui m’a poussé à étudier la technique au travers d’Ellul, Mumford, Illich et d’autres. Je lui dois mon intérêt pour le phénomène technicien et souhaitais le relire, quatre ans et de nombreuses lectures après. Cet article présente les deux faces indissociables de Kaczynski : le penseur et le militant.

Le militant

Sa carrière de terroriste est entièrement ordonnée à la diffusion de sa pensée. L’analyse de ses actes révèle une intelligence stratégique et une méticulosité hors du commun. Kaczynski commence par envoyer une série de colis piégés assez artisanaux, afin de créer une agitation médiatique. Il prend bien soin de ne laisser aucune trace et se paye même le luxe de semer des fausses pistes. Après cela, il se retire pendant 6 ans, créant une attente immense auprès du grand public. Il aurait employé ce temps à peaufiner son manifeste.

La seconde phase commence en 1993 lorsque le criminel le plus célèbre des Etats-Unis refait surface. Prenant appui sur son immense renommée, il démarre une nouvelle campagne d’envoi de colis piégés, cette fois létaux et accompagnés de lettres. Il demande la publication de son manifeste, en échange de quoi il cessera de tuer. Faute de pistes sérieuses, le FBI recommande d’accéder à son souhait, dans l’espoir que quelqu’un reconnaisse l’auteur du manifeste.

Confondu par son frère, Kaczynski est arrêté le 3 avril 1996 dans sa cabane. Il a 54 ans, son manifeste est publié et ses actions terroristes ont donné à ses idées un écho gigantesque. Le dernier tour de force de Kaczynski fut d’être reconnu sain d’esprit lors de son procès, contre l’avis de nombreux psychiatres, tout en évitant l’exécution. Une irresponsabilité pour démence aurait été un accroc majeur dans la diffusion de ses idées.

Depuis sa cellule Kaczynski a publié plusieurs ouvrages, dont une version actualisée de son manifeste. Il communique avec ses contradicteurs et continue de rayonner. Il s’est fait capturer à un âge ou sa force physique devenait incompatible avec la vie sauvage. Sans doute envisageait-il la prison comme une retraite, qu’il pourrait employer à diffuser sa pensée. Il n’avait de toutes façons pas d’autres alternatives.

Nonobstant la question morale, la carrière d’Unabomber est un sans-faute. La succession de ses actes est une partie d’échecs : actions, retraites, tout est pensé longtemps à l’avance. Kaczynski laisse peu au hasard et déploie toute la force de son intelligence au service de sa cause. Il est bien loin de l’image du fou aveugle véhiculée par les médias. Si nous écartons son mode d’action, il est un exemple de militant efficace.

Le penseur

Dans l’imagerie médiatique, Unabomber est un tueur nihiliste, tentant de justifier ses actes par une pensée incohérente. La lecture de son manifeste révèle au contraire une réflexion certes radicale, mais très profonde, puisant ses racines dans des auteurs français et américains. La pensée de Kaczynski est une vulgarisation de celle de Jacques Ellul, il puise des inspirations dans La France contre les Robots de Bernanos et utilise des expressions propres à Lewis Mumford, Sigmund Freud ou bien Aldous Huxley.

Kaczynski résume lui-même sa pensée en quatre maximes :

Le progrès technologique nous conduit à un désastre inéluctable ;
Seul l’effondrement de la civilisation moderne peut empêcher le désastre ;
La gauche politique est la première ligne de défense de la Société technologique contre la révolution ;
Ce qu’il faut, c’est un nouveau mouvement révolutionnaire, voué à l’éradication de la société technologique, et qui prendra des mesures pour tenir à l’écart tous les gauchistes et consorts.

Tout au long de son manifeste, dans un style simple, clair et sans concessions, Kaczynski développe sa pensée. Loin d’être un pur théoricien, Kaczynski explique concrètement comment pousser la société industrielle jusqu’à son point de rupture, afin de la détruire pour qu’elle ne réapparaisse plus. Il est un militant et ce document est destiné à d’autres militants. Il ne croit absolument pas au pouvoir des masses, mais à celui des minorités agissantes, à qui il s’adresse.

Beaucoup de ceux qui n’ont pas lu Kaczynski le prennent pour un primitiviste et rejettent à raison cette pensée. Pourtant celui-ci a bien pris soin de se distinguer de ces derniers, notamment dans une série de lettres à John Zerzan. Unabomber ne souhaite pas un retour à l’âge de pierre, mais une société décentralisée, composée de paysans, d’éleveurs, de chasseurs et d’artisans, vivant en petites communautés et usant d’une série de techniques simples, dont la portée ne dépasse pas les terres environnantes. Il reprend la distinction entre Technique et techniques faite par Ellul, sous le vocable plus clair de « techniques cloisonnées » et « techniques systémiques ». Une technique cloisonnée est, pour lui, une technique pouvant être mise en œuvre par une poignée d’artisans et utilisant les ressources produites par les terres environnantes. Une définition fort intéressante à la veille d’une crise majeure de l’énergie, qui pourrait bien sonner le glas d’une révolution industrielle somme toute très récente à l’échelle des temps humains.

Nouvelles subsidiarités : Quel est le rôle social des entreprises ?

Thu, 05 Jan 2017 00:00:00 +0000

L’entreprise au début de l’ère industrielle avait pour mission de fournir un bien ou un service de manière rentable. La main invisible du marché devait se charger de redistribuer les richesses, afin d’amener aux hommes bonheur et abondance. A l’époque il avait même été décrété que rien ne devait exister en dehors de l’entreprise, c’est dire si on y croyait. Adieu corporations, jurandes et autre reliquats d’une époque sombre. Le travailleur orphelin fut confié à sa marâtre : l’entreprise. Celle-ci devint le seul corps intermédiaire reconnu par la République.

Depuis, lorsque la société civile rencontre un problème, il est obligatoirement imputé à l’état ou aux entreprises, seuls corps sociaux significatifs. L’état répondra souvent par des lois qui vont s’accumuler. L’inflation législative va créer de nouveaux rôles à l’entreprise, pour lesquels elle n’est souvent pas outillée. A l’entreprise moderne, on demande d’être sobre en ressources, de ne pas polluer, de respecter les droits des animaux, d’insérer les personnes en difficulté, de ne pas discriminer les personnes transgenres issues de la diversité, de ne pas réduire ses salariés en esclavage et de ne pas trop escroquer ses clients, tout en restant rentable, rien que cela ! Tous ces rôles, autrefois assumés par des corps intermédiaires spécialisés, se retrouvent désormais dans l’indigeste notion de « Responsabilité sociétale des entreprises ».

L’entreprise n’a pas vocation à être l’avocat de la nature, la protectrice de la veuve intérimaire et du stagiaire orphelin ou la garante des règles de l’art. Son rôle est de produire de la richesse. L’état se fourvoie lorsqu’il greffe artificiellement des rôles sociaux à l’entreprise : elle cherchera toujours à les esquiver. L’entreprise doit avoir des responsabilités, mais elle ne saurait avoir un autre rôle que la création de richesse.

Les rôles sociaux doivent être joués par des corps intermédiaires dont l’intérêt intrinsèque est de les assumer, par exemple les corporations, les syndicats ou les corps territoriaux. Ces corps ne doivent surtout pas tirer leur pouvoir et leur légitimité d’une patente étatique, mais des personnes qui les composent. Ce sont les frictions entre ces corps intermédiaires arbitrées subsidiairement par le pouvoir politique, qui doivent définir les règles.

En détruisant les corps intermédiaires, les libéraux ont créé une bombe à retardement : la société ne cesse pas d’avoir des revendications et faute d’exutoire, c’est l’entreprise qui doit y faire face. L’entreprise doit redevenir un corps social comme un autre si elle ne veut pas couler sous le poids des rôles artificiels que la société lui attribue. Son rôle privilégié en fait la cible des demandes les plus légitimes, comme les plus illégitimes. Le millefeuille règlementaire qui en résulte la tue.

Rue Steve Jobs : Les précurseurs français d'Internet oubliés

Thu, 15 Dec 2016 00:00:00 +0000

Quel est le point commun entre Louis Pouzin, Gérard le Lann, François Flückiger, le projet CYCLADES et le Minitel ? Ils sont français, ont eu un rôle majeur, sinon crucial dans le développement de l’Internet moderne et n’ont pas de rue à leur nom. Contrairement à Steve Jobs, immortalisé par le maire socialiste du XIIIème arrondissement, qui aura prochainement sa trimarde dans la capitale.

Sans la France, sans ces ingénieurs aujourd’hui oubliés, Internet n’existerait pas. Peut-on en dire autant de Steve Jobs ? Rappelons le passif du personnage : commercial de génie, n’ayant jamais rien produit par lui-même ; véritable tyran d’entreprise, terrorisant tout autant ses salariés américains que les esclaves chinois travaillant pour lui ; fossoyeur de l’Internet libre, préférant un écosystème logiciel fermé et honteusement cher. Le personnage est bien sûr loué par tous les bien-pensants, les guerriers de la justice sociale et autres consommateurs de café équitable, plus avides de conformisme que de cohérence. Ils voient en lui un « visionnaire », un « innovateur », un « génie parti trop tôt » voire même un « artiste du capitalisme », bigre !

En France, ce pays d’ingénieurs de haut vol, les élus socialistes préfèrent un escroc, un imposteur et un marchand aux dignes artisans d’Internet. Faire de Jobs un modèle pour la jeunesse, c’est encourager le pillage anglo-saxon sur l’inventivité française. C’est gonfler l’égo de commerciaux déjà pleins de morgue. C’est encore un fois rabaisser la valeur du travail honnête et rémunérateur pour encourager le vol, la spéculation et la médiocrité. C’est donner raison à la consommation compulsive d’appareils monolithiques, jetables lorsqu’une nouvelle version sort.

Une rue qui a toute sa place dans le Paris du XXIème siècle, hélas.

Louis Pouzin est l’inventeur du datagramme, capsule de données à la base des réseaux informatiques, dont Internet.
Gérard Le Lann est un des architectes des protocoles TCP/IP, squelette de l’Internet moderne. TCP est une amélioration du datagramme de son collègue Pouzin.
François Flückiger, scientifique au CERN, est un des bâtisseurs du réseau Internet européen contemporain.
Le projet CYCLADES fut une expérience française (IRIA) de réseau alternatif à ARPANET. Ce fut finalement ce dernier qui servit de base à Internet, non sans avoir absorbé les bonnes idées et la plupart des ingénieurs du premier. Sans CYCLADES, ARPANET n’aurait probablement pas été viable et Internet n’aurait pas existé.
Le Minitel fut un réservoir d’idées pour l’Internet naissant à l’époque. Il lui est injustement reproché le retard d’accès à Internet des Français.

L’informatique a-t-elle un avenir ?

Sat, 15 Oct 2016 00:00:00 +0000

Récemment, le président Barack Obama a accordé un entretien au magazine Wired[i], sur la robotisation, l’Intelligence Artificielle et la réduction du temps de travail. Le président américain prédit un avenir ou le travail humain sera remplacé progressivement par des machines, et les bénéfices reversés à la société toute entière. Un discours vieux de deux siècles, sans cesse remis au goût du jour[ii].

De notre point de vue, un futur où le travail est robotisé n’est absolument pas crédible. Nous allons même plus loin, en déclarant que dans la majorité de ses usages actuels, l’informatique n’a aucun avenir. Le monde de demain sera contraint en énergie, soit par manque de ressources, soit afin de ne pas dérégler massivement le climat. La plupart des spécialistes s’accordent à le dire : les énergies fossiles en général et le pétrole en particulier, voient déjà leur production décroître[iii] et ni les renouvelables, ni la fusion ne viendront nous sauver dans les prochaines décennies[iv]. La récession actuelle est donc là pour durer, balayant sur son passage tout l’accessoire.

Soyons clairs : l’informatique n’est pas économe. Les immenses fermes de serveurs, les innombrables routeurs assurant le transit mondial des données, les nombreux ordinateurs personnels et autres gadgets connectés consomment environ 10% de l’électricité mondiale[v], soit l’équivalent de la production d’électricité nucléaire.

Les utilisations de cette technologie sont, pour la plupart, soit énergivores, soit accessoires, soit les deux. Dans un monde contraint en énergie, l’informatique n’aura sa place que dans deux cas de figure : le remplacement de secteurs encore plus énergivores qu’elle et un nombre réduit de secteurs coûteux en énergie, mais pour lesquels les particuliers, les entreprises ou l’état sont prêts à payer cher. L’informatique de remplacement inclut par exemple les solutions de vidéoconférence, se substituant aux voyages en avion dans les milieux d’affaires. L’informatique énergivore est par exemple le e-commerce, pure annexe des transports. Il est à parier que les usages récréatifs et/ou nuisibles (pornographie notamment) deviendront un plaisir d’élite s’ils ne disparaissent pas complètement.

L’informatique de masse ne peut pas être viable. L’épuisement des terres rares va rendre obligatoire le recyclage minutieux de chaque unité, renchérissant le coût en énergie de chaque unité produite. Dans un contexte de tensions énergétiques, cela signifie un prix croissant des nouvelles machines. La mutualisation des machines risque de devenir la norme et le PC personnel un luxe. L’accroissement de la puissance de calcul unitaire devrait ralentir, pour se caler peu ou prou sur l’accroissement de l’efficience énergétique. La consommation énergétique par unité a peu de chances d’augmenter dans les machines grand public.

Si nous devions nous risquer à dessiner l’avenir chez les particuliers, ceux-ci recentreront sans doute leurs moyens autour d’un PC familial, doublé d’un smartphone professionnel basique selon les cas, le tout communiquant avec un nombre plus limité qu’aujourd’hui de services. L’avenir ne sera certainement pas dans la prolifération des sex toys connectés et autres brosses à dents intelligentes.

Du côté des entreprises, seules celles qui trouveront un avantage réel à s’informatiser davantage le feront. L’effet de mode et la simple technophilie cèderont la place au dur calcul économique. Le secteur numérique, aujourd’hui en plein boom, pourrait se retrouver du jour au lendemain en grave crise, comme lors de l’explosion de la bulle Internet. Brisons de suite un mythe répandu : non, le tertiaire n’est pas économe en énergie. Mettre quelqu’un dans un bureau signifie qu’il faut le remplacer par une machine dans le secteur primaire ou secondaire.

Dans les gros systèmes centralisés, la part de l’énergie consacrée au fonctionnement du système lui-même, par rapport aux applications hébergées augmente[vi]. La tendance sera donc à la décentralisation et aux systèmes distribués, dès que les économies d’échelle auront été annulées par le renchérissement du coût de l’énergie.

Les utopies californiennes d’un monde où robots et intelligences artificielles remplaceraient les humains à la tâche prennent du plomb dans l’aile. Le remplacement de l’homme par la machine ne vaut que tant que le coût de l’heure de fonctionnement de celle-ci (incluant son amortissement), dépasse les salaires des ouvriers qu’elle remplace. Le renchérissement du coût de l’énergie viendra rapidement remettre l’homme au travail. Les bras aujourd’hui au chômage ne suffiront pas à combler le manque d’énergie qui s’annonce. La « crise » de 2008 n’en est pas une. Elle est le début d’une récession mondiale après le passage du pic pétro-gazier. Cette récession remet en question de nombreux « progrès » de la société moderne, qui fondront comme neige au soleil face à la dure réalité physique. L’informatique en fait partie, tout comme l’internet libre, très belle idée, hélas irréaliste dans un monde à l’énergie contrainte.

[i] https://www.wired.com/2016/10/president-obama-guest-edits-wired-essay/

[ii] JARRIGE François, Technocritiques

[iii] En 2010, l’Agence Intenationale de l’Énergie déclarait que la production de pétrole ne dépasserait jamais le niveau de 2006 : le fameux pic du pétrole.

[iv] La fusion commerciale est estimée au mieux pour 2090

[v] Cloud begins with Coal, Digital Power Group, 2013

[vi] LUSSATO Bruno, La Troisième Révolution

Critique de Deux Ex : Mankind Divided

Thu, 22 Sep 2016 00:00:00 +0000

Deus Ex : Human Revolution était un jeu équilibré, soulevant des questions sur le transhumanisme, tout en laissant le joueur y répondre. Le personnage de Jensen, augmenté malgré lui était parfait pour cela. Les trois fins possibles étaient d’une finesse suffisante pour alimenter un débat sérieux. A l’inverse, Mankind Divided est une daube infâme. Dans ce jeu, nous retrouvons le même Jensen, dans un monde où les augmentés sont traités en parias et déportés, à la suite des évènements de Human Revolution. Les scénaristes ont arbitrairement choisi l’une des 3 fins possibles du précédent opus. La mission de Jensen est de déjouer un complot illuminati (oui, oui) visant à éliminer les augmentés !

Les missions secondaires sont sans saveur, la ville de Prague, petite et inintéressante. Human Revolution nous avait habitué à mieux : les immenses villes de Hengsha ou Detroit.
Les graphismes sont les mêmes que ceux du précédent opus, à quelques fantaisies près (histoire de justifier l’achat d’une carte graphique). Je jeu n’est pas toujours très fluide. Aucune nouveauté dans le gameplay, juste quelques gadgets assez inutiles.

Mankind Divided est une mauvaise œuvre de propagande, un jeu bâclé destiné à remplir les poches de son éditeur en débitant un scénario improbable et fade.

Le comble ? Le fil rouge du jeu est la dénonciation des mass médias servant de la propagande.

Joyeux anniversaire Linux !

Wed, 31 Aug 2016 00:00:00 +0000

Linux fait figure d’exception dans le monde de l’ingénierie logicielle. Il est le seul projet libre de cette ampleur à fonctionner depuis 25 ans. Linus Torvalds, son créateur, le dirige encore aujourd’hui d’une main ferme, à la manière d’un véritable monarque.

Comme tout logiciel libre, Linux peut être utilisé, modifié, dupliqué et diffusé sans aucune contrainte. Sa spécificité vient de la propriété de la marque Linux par Linus Torvalds. N’importe qui peut installer Linux, le modifier et diffuser ses modifications, mais seul Linus Torvalds décide des modifications qui seront incluses dans le logiciel désigné par le nom de Linux. Chacun est en revanche libre de publier des modifications refusées sous un autre nom. Pourtant, la popularité de Linux empêche bien souvent les mécontents de s’éloigner de la branche principale. Cela garantit une certaine stabilité au projet Linux.

Dès les premières années du projet, des centaines de développeurs sont venus contribuer librement au projet Linux. Cette communauté produisait trop de modifications pour que Linus puisse seul les analyser et les incorporer à Linux. Il a donc décidé la création d’un système de lieutenants, un pour chaque grande partie du système (son, processeur, mémoire …). Chaque lieutenant est responsable devant lui de la qualité du code qu’il valide. Tout développeur qui souhaite contribuer au projet Linux doit envoyer ses modifications à un lieutenant, qui validera ses modifications et les regroupera avec d’autres, afin de les présenter à Linus. En cas de conflit entre deux lieutenants, Linus tranche, avec un langage souvent très fleuri. Ce système dure encore aujourd’hui, alors que des milliers de développeurs contribuent au plus gros projet libre du monde.

Basés sur l’idéologie libertaire du logiciel libre, beaucoup de projets échouent faute d’une vision cohérente. La gestion de projet monarchique de Torvalds a protégé Linux des scissions et des affrontements d’égos, lui permettant de dépasser la barre des 25 ans. Il n’est pas pour autant un tyran : il juge les modifications sous l’angle du bien du projet et laisse des libertés partout où les règles ne sont pas nécessaires. Si cela n’avait pas été toujours le cas, les développeurs seraient simplement partis. Le projet aujourd’hui est assez stable et sérieux pour que des grandes entreprises allouent des centaines de salariés au développement de Linux.

Le principal point faible de Linux est la succession de Torvalds : aucun successeur n’a été désigné ou ne ressort. Il est certain que sans ordre, sans chef et sans guide, la communauté linux deviendra pauvre troupeau. Il n’y a pas encore lieu de s’alarmer, à 46 ans, le « dictateur bienveillant » se porte bien. Néanmoins, la communauté linux devrait sérieusement réfléchir à la question. En attendant, joyeux anniversaire Linux !

L’histoire de Linux débute le 25 aout 1991, à l’université d’Helsinki. Linus Torvalds, alors étudiant décide de développer un émulateur de terminal pour remplacer celui présent sur son ordinateur. Cet émulateur fut le point de départ d’un système aujourd’hui connu sous le nom de Linux.

Il totalise à ce jour plus de 10.000 développeurs et 1000 entreprises ayant contribué à son développement. Le noyau Linux équipe 31% des tablettes et 64% des smartphones grâce à Android. 38% des serveur tournent sous Linux, de même que la quasi-totalité des superordinateurs (97%) et des systèmes embarqués (domotique, audiovisuel …). Linux est minoritaire (1,7%) sur le seul segment de l’informatique grand public, pour combien de temps encore ?

Pour aller plus loin : http://www.silicon.fr/linus-torvalds-linux-75664.html

Lire ou relire Ivan Illich

Wed, 20 Jul 2016 00:00:00 +0000

Tout système, lorsqu’il dépasse une certaine importance, finit par devenir contre-productif, puis par nuire à la société. C’est l’audacieuse thèse développée par Ivan Illich (1926-2002), prêtre catholique défroqué et l’un des plus lucides critiques de la société industrielle.

Défenseur d’une société de la liberté de faire, contre la société industrielle où l’homme est seulement libre de consommer, Illich est un penseur des libertés. Ses travaux l’ont amené à un constat : chaque producteur de biens ou de services, lorsqu’il a dépassé une certaine taille, finit irrémédiablement par devenir contre-productif.

Illich développe ce constat en analysant dans les années 70 plusieurs institutions de la société industrielle : le système éducatif dans Une société sans école, la médecine moderne dans Némésis médicale ou bien l’infrastructure de transport dans Énergie et équité. Chacun de ces livres est édifiant, brisant bien des mythes que l’homme moderne tend à croire : la médecine moderne apporte plus de maladies iatrogènes qu’elle ne soigne de malades ; l’école délégitime l’apprentissage autodidacte et tue la curiosité naturelle de l’homme ; l’habitude du transport motorisé place les choses à une distance que ne peuvent plus franchir les autres moyens de déplacement.

Loin de se cantonner à la critique, Illich n’hésite pas à proposer des outils conceptuels, afin que l’homme reprenne le contrôle sur la machine. La Convivialité, à la fois ouvrage et concept distingue les outils, que l’homme utilise comme bon lui semble, des machines, qui créent des besoins auquel elles-seules peuvent répondre. Un outil convivial est un outil dont l’utilisation ne retire pas de libertés. Plus grille de lecture que praxis, la convivialité n’en est pas moins utile pour critiquer la plupart des institutions modernes sur leur prétendue utilité sociale.

Illich parle peu de politique, mais en parle efficacement. Il souhaite une société décentralisée, hérissée des libertés dont nous ont privé les institutions industrielles. Il est cité à juste titre comme l’un des pères de la décroissance, même s’il convient de faire attention avec ce terme aujourd’hui. Illich souhaite que la créativité humaine remplace la stérilité morbide des institutions industrielles. Il appelle à une innovation authentique, à un homme qui créé lui-même les outils dont il a besoin, plutôt que de consommer toujours plus. En bon chrétien, il souhaite que pauvreté ne soit plus un gros mot, mais l’inverse de la misère, déchet d’industrie. Le pauvre devient misérable lorsqu’on le prive de la possibilité de faire les choses par lui-même, lorsqu’il devient un consommateur sans le sou. Nos paysans d’autrefois étaient certainement pauvres, jamais misérables.

En France les thèses d’Illich ont été oubliées (jugées trop pessimistes par la gauche après l’élection de Mitterrand), elles n’ont pas été infirmées. Ses analyses sont plus que jamais d’actualité dans notre pays, quand la République souhaite museler l’école libre et remplacer le bocage vendéen par un aéroport démesuré. Le sociologue Jean-Pierre Dupuy, un des principaux disciples d’Illich revendique l’héritage de son maître, de même que certaines chapelles d’écologistes. Beaucoup de décroissants s’en revendiquent, certains sont légitimes, d’autres, fieffés étatistes ou écocentristes incurables, moins. Sa pensée mériterait d’être étudiée par tout ennemi de la civilisation des machines et par tout écologiste intégral consciencieux.

Bibliographie

La carrière d’écrivain d’Illich dure 20 ans, de 1971 à 1991. En 1971 sort Libérer l’avenir, expliquant les raisons de son départ de l’Église (Illich a défroqué en 1966), tout en constituant une sorte d’introduction à ses œuvres futures. La même année sort Une société sans école, ouvrage critiquant le système scolaire, présenté comme un frein à la curiosité personnelle et à l’apprentissage traditionnel de maître à élève. En 1973 sortent deux ouvrages importants : La Convivialité et Énergie et équité. Le premier est la synthèse des travaux du CIDOC par Illich, le second une critique de l’inégale répartition de l’énergie comme cause de la misère mondiale. Enfin, en 1975 Némésis médicale vient attaquer frontalement la médecine moderne, intouchable dés lors.

En 1976 le CIDOC est liquidé par Illich, qui retourne en Europe. La suite de son œuvre est d’un autre ton, bien plus marquée à gauche et parfois très discutable. Le chômage créateur (1977), postface de La Convivialité développe la notion de monopole radical, jusqu’à accuser l’Église d’être à l’origine de ces institutions modernes qui rendent obligatoire leur médiation. Le Travail fantôme (1981), traite de la dépendance de l’emploi moderne au travail non rétribué. Le Genre vernaculaire (1983) est un essai philosophique sur la notion de genre. H2O ou les eaux de l’oubli (1988) retrace l’histoire de l’eau, jusqu’à la société industrielle qui l’accapare. ABC, l’alphabétisation de l’esprit populaire (1990) est une critique de l’alphabétisation qui a tué l’oralité. Enfin Du lisible au visible, la naissance du texte (1991) est une critique du Didascalicon de Hugues de Saint Victor. La correspondance d’Illich est à ce jour inédite.

L'État brade nos données

Wed, 06 Jul 2016 00:00:00 +0000

« La France porte une tradition de transparence démocratique et de partage des informations détenues par la puissance publique. » Ne riez pas, il s’agit des premiers mots de la très sérieuse déclaration du gouvernement sur l’ouverture des données publiques. Notre pays va d’ailleurs prendre la tête du Partenariat pour un Gouvernement Ouvert (PGO) en octobre prochain. L’ouverture et la transparence comme remède au complexe démocratique de la république ? Tout un programme.

L’ouverture des données publiques est constamment demandée tant à gauche qu’à droite. Les premiers soutiennent que l’accès aux données publiques est un enjeu démocratique, inscrit dans les Droits de l’Homme, les seconds veulent dynamiser l’économie en injectant les données publiques dans un marché déjà fort lucratif. Les plus radicaux des deux camps vont même jusqu’à exiger la fin du secret d’état, qui mettrait gravement en danger les capacités stratégiques de celui-ci.

Cela va sans dire que tout politique d’ouverture de données multiplie forcément le nombre d’accès aux systèmes d’information, donc le coût en infrastructures. Une aubaine pour les constructeurs, les équipementiers et les SSII. Cela n’étonnera donc personne que les deux plus généreux donateurs du PGO soient la fondation Hewlett et le réseau Omidyar[1].

L’ouverture des données publiques se révèle une manne pour les entreprises : Incapable depuis des années d’en faire quelque chose d’utile, l’état va ouvrir diverses données, donc permettre au privé de les utiliser à but lucratif. Une fois les données mises en ligne, y compris si l’état tente d’en restreindre l’accès, le monde entier pourra les copier, les stocker et les traiter. Internet n’a pas de frontières, ni de droit de retrait.

Ces données « publiques », en réalité les données des français, vont être livrées au monde marchand et à l’étranger, par décision unilatérale de l’état. Elles seront au départ très incomplètes, mais de plus en plus de points d’entrée (API) vont être créés, livrant toujours plus de données. De surcroit, l’état s’introduit de plus en plus profondément dans la vie privée des français. Chaque nouveau rôle que se donne l’état, c’est aussi de précieuses données qui viennent enrichir ses bases. Pour l’instant la CNIL veille au grain quant à l’anonymisation des données. N’oublions pas qu’elle n’existe que grâce à la volonté de l’état. Déjà très critiquée par ceux qui souhaitent libéraliser le marché de la donnée, elle pourrait tôt ou tard céder. Rien n’interdit non plus à l’état de vendre des jeux de données au privé ou de fournir des données à des entreprises, dans le cadre de partenariats public-privé, cela se voit avec EDF.

La confiance que les français plaçaient dans l’état, concernant les informations qu’ils lui livraient (de gré ou de force) est trahie. Le citoyen devra se consoler au choix avec des droits de l’homme mieux respectés ou bien des points de croissance dont il ne verra pas la couleur.

[1] La fondation Hewlett a été fondée par l’ancien PDG de HP, le Omidyar Network par le fondateur d’eBay.

Vincent Desportes : La voix de la Grande Muette

Mon, 04 Apr 2016 00:00:00 +0000

Je me suis rendu, en tant qu’ambassadeur du Portail de l’IE, à la conférence du Général Vincent Desportes autour de son livre La dernière bataille de France.

Le général débute sa conférence par un effrayant portrait de l’armée française, parent pauvre de la république. Meurtrie par des politiques incapables de se projeter dans le long-terme, affaiblie par un budget anémique et démantelée par l’absurdité bureaucratique, notre outil de défense est bien malade.

Le général poursuit son propos en tentant d’expliquer les raisons de ce déclin de l’armée. Pour lui, elles sont multiples : la bureaucratie et ses conséquences ont fondu sur les militaires : technologisme, rigidité, absurdité et réformite. La dissuasion nucléaire a servi de prétexte pour faire fondre les budgets conventionnels. Le pacifisme et l’antimilitarisme, déjà hors d’âge pendant la guerre froide, continuent d’être présents dans les plus hautes sphères de la république, à gauche comme à droite. Enfin, les français vivent dans l’illusion que l’Oncle Sam reviendra nous sauver, à moins qu’une chimérique défense européenne n’émerge après 60 ans de coma.

Le général Desportes termine sa conférence en exhortant les français à se réveiller. Ils doivent exiger leur protection, qui leur est due par l’état. Le régalien n’aura jamais été aussi ignoré qu’aujourd’hui. L’armée est l’assurance de la nation, ça n’est pas le jour où un problème survient qu’il faut s’en soucier. Sans l’armée Japonaise, Fukushima aurait été bien pire. Sans épée, les valeurs sont de vains mots. Si nos valeurs reculent y compris chez nous, une des causes est l’affaiblissement du militaire.

Avec un budget de 1.51% du PIB, notre armée n’aura bientôt plus la capacité pourtant cruciale de se projeter en opérations extérieures. L’armée manque d’hommes et d’argent, les exigences politiques n’arrangent rien : plus notre armée se projette en OPEX, plus elle s’appauvrit, ce temps et cet argent est pris sur la maintenance et l’entraînement. L’opération Sentinelle, véritable gâchis d’argent public (d’autres peuvent parfaitement remplir cette mission, un soldat coûte trop cher pour faire le guet dans la rue), empire la situation. La somme rendue aux armées après Charlie ne change rien : c’est un adoucissement du coup de rabot qui ne rattrapera pas 25 ans de disette budgétaire.

Il dénonce des conduites d’opérations parasitées par les politiques. On ne dimensionne plus une opération en fonction des besoins stratégiques, mais en fonction de l’argent disponible. Les économies de bout de chandelle, souvent périlleuses pour les soldats, sont légion : lorsqu’un soldat pose son pied en terre étrangère, l’objectif n’est plus de remplir la mission, mais de le rapatrier le plus vite possible, afin de faire des économies. Ses camarades restés sur le terrain courent un risque majoré. L’opération Sangaris est un cas d’école : 3500 hommes et 8 hélicoptères pour couvrir un territoire de la taille de l’Europe.

Les politiques sont également responsables d’avoir jeté en pâture l’armée aux bureaucrates. La LOLF a fait disparaître l’État-Major des décisions budgétaires : le chef d’état-major seul est codécisionnaire avec deux hauts-fonctionnaires. La RGPP a poussé à outrance la fusion interarmées des métiers. Or, souligne le général, un cuisinier au sol de l’armée de l’air n’a rien à voir avec un cuisinier de l’armée de terre, qui peut cuisiner en pleine bataille ! La matricialisation des armées a supprimé le lien hiérarchique unique au profit d’une irresponsabilité générale. Le larcin de Miramas, où aucun responsable n’a été trouvé illustre bien le problème. Enfin, le DRH des armées est un civil : tout un symbole.

Le lien complexe entre une armée anémique et un complexe militaro-industriel devant être bénéficiaire pour survivre ont créé un autre monstre : le technologisme. Pour que l’industrie militaire française, gage d’indépendance, survive, l’armée doit commander toujours plus de nouveaux matériels. Or l’armée n’a pas les moyens d’équiper toutes ses unités. La solution trouvée est de diminuer la taille des corps d’armée en fonction du nombre d’équipements dernier-cri que l’on peut se payer. Or la matière première d’une armée c’est l’homme, pas le matériel. Sous une certaine masse critique, une armée passe en état d’insignifiance stratégique.

Pour toutes ces raisons, l’armée française est devenue une armée coup de poing, frappant brièvement mais s’essoufflant vite. Cela conduit à des victoires tactiques mais à des échecs stratégiques. Cette demi-mesure permanente est une catastrophe : nous avons assez bombardé Daech pour provoquer le Bataclan et Bruxelles, pas assez pour les atteindre.

Le général le rappelle : l’armée correspond à la vision militaire du chef d’état. Or les chefs d’état récents n’en ont pas eu. Ils n’ont jamais eu non plus de vision globale de l’appareil militaire, souvent par manque total d’intérêt pour la chose. Ce qui n’empêche pas les chefs d’état d’intervenir à l’extérieur, pour des raisons souvent situées dans le court-terme et sans donner à l’armée les moyens d’intervenir. Pour le général Desportes, un pays comme le nôtre devrait consacrer 3% de son PIB à son armée. Nos interventions fréquentes à l’étranger et la taille de notre zone maritime le justifient.

Alors que le monde d’aujourd’hui est plus belliqueux et chaotique qu’il ne le fut pendant la guerre froide, les budgets diminuent. Un pacifisme et un antimilitarisme d’un autre âge continuent de hanter les couloirs des ministères : le soldat dérange car il rappelle le tragique du monde. Le pouvoir, de droite comme de gauche, craint l’armée car le souvenir du Putsch des Généraux de 1961 est encore vif. Enfin, le système politique actuel n’arrive pas à faire émerger la stabilité nécessaire à l’armée. Ce que font les uns est défait par les autres, au gré des changements de majorité.

Le parapluie américain se referme, pourtant les français croient encore que l’Oncle Sam reviendra les sauver en cas de pépin. Le général Desportes piétine cette illusion : le soldat Ryan ne reviendra plus mourir pour sauver l’Europe. Les intérêts économiques américains ont changé, de même que l’ethnie dominante. Les caucasiens seront bientôt minoritaires et ni les latinos, ni les noirs n’identifient l’Europe comme leur « Grand-Mère patrie ».

La défense européenne, seconde illusion française n’a que peu de chances d’émerger un jour. Elle n’a même aucune chance d’émerger sans une armée française saine et forte. En détruisant l’armée, ceux qui croient en la défense européenne nuisent à leur propre cause. L’addition des faiblesses n’a jamais fait de forces. De plus, l’Union européenne, en voulant syndicaliser les armées, ne chemine pas vers un système de défense efficace.

La troisième illusion française est la dissuasion nucléaire. La Bombe est utilisée comme prétexte pour faire baisser les budgets conventionnels. Sauf que personne n’a jamais vu une tête nucléaire libérer des otages ! Les dirigeants oublient souvent que la dissuasion nucléaire n’est efficace que si le pays dispose de sa pleine autonomie stratégique. Or, notre armée dépend du ravitaillement américain pour intervenir. La dissuasion nucléaire est fortement handicapée aujourd’hui.

Le général clôt sa conférence en rappelant le rôle fondamental d’une armée, surtout dans un pays de tradition militaire comme la France. Il en profite pour exposer les enjeux de demain, qui rendront l’armée encore plus indispensable à la survie de notre pays.

L’armée, dit-il, est une assurance. Lorsque plus rien ne fonctionne dans un pays, l’armée est là. Le rôle de l’armée japonaise après la catastrophe de Fukushima ou bien le rôle de l’armée française après Xynthia le prouvent. Ça n’est pas le jour où nous sommes en danger mortel qu’il faut songer à prendre sa police d’assurance. Une armée est un outil qu’il est facile de briser mais difficile d’aiguiser. 25 ans de destruction ne se rattrapent pas comme cela.

L’armée est aussi un pilier de la nation. Sans épée pour les protéger, les valeurs sont de belles paroles. Si les valeurs françaises refluent, y compris chez nous, le déclin de l’armée y est pour quelque chose. Si nous voulons exister, l’état doit à nouveau se concentrer sur le régalien, si longtemps délaissé.

La France est en danger de mort prévient le général : dans 20 ans, 1 milliard d’Africains de plus seront nés. Si l’Afrique n’est pas stabilisée, ces africains ne resteront pas en Afrique. L’actuelle crise des migrants paraîtra ridicule à côté de ce tsunami. De par son histoire, c’est à la France d’aider ce continent à se stabiliser, aucune autre puissance ne le fera. Il faut rompre la politique amorcée par Mitterrand à La Baule. Cela requiert une armée saine et nombreuse.

Éric Delbecque : Idéologie sécuritaire et société de surveillance

Mon, 21 Mar 2016 00:00:00 +0000

Nous sommes tous Big Brother ! C’est l’audacieuse thèse d’Éric Delbecque développée dans son dernier essai : Idéologie sécuritaire et société de surveillance.

Il n’y a pas selon l’auteur d’idéologie sécuritaire à proprement parler, portée par une poignée d’idéologues à la tête de l’État. Pour lui, le problème est plus profond : la mort de l’idée de Progrès, énergie vitale des sociétés occidentales depuis les Lumières, a plongé les Occidentaux dans un malaise profond. Sans futur, sans projet fédérateur, les Occidentaux se replient sur eux-mêmes et forment une société de défiance permanente.

La peur dans la société du spectacle

L’auteur commence par un constat : le monde n’est pas plus violent aujourd’hui qu’hier, mais la violence a changé de forme. On peut dire sans risque que le niveau de violence des sociétés européennes a diminué depuis deux siècles. En revanche ça n’est pas le cas dans le reste de monde. De plus, des foyers d’ultra violence ont émergé, laissant croire à un ensauvagement généralisé.

Le plus grand changement du XXème siècle est la diminution des violences entre États. Lors d’une guerre, les camps sont clairement définis et l’attention est focalisée sur l’ennemi du dehors. L’ennemi commun soude les communautés. En temps de paix prolongée comme actuellement, la violence du quotidien monopolise les esprits. L’ennemi n’est plus en face : il est potentiellement partout. Le paradoxe de Tocqueville vient renforcer cette peur de l’ennemi intérieur : moins il y a de violence dans une société, moins la violence résiduelle est tolérée.

À cela viennent s’ajouter les exigences de la société capitaliste : il faut une population aussi obéissante dans le travail que dans la consommation. Nous vivons dans une sorte Meilleur des mondes qui se serait mélangé à un 1984 orwellien. Le soma qu’est l’hédonisme ne suffit pas à contrôler les populations, il faut également instrumentaliser la peur, en faire un spectacle au sens où l’entend Guy Debord. Désormais le crime est médiatisé, scénarisé afin de divertir. La boucle de la décadence est lancée : le plaisir conjure l’angoisse, la violence-spectacle la ramène. Si cela peut en plus faire les affaires d’un business de la sécurité, c’est encore mieux.

Sortir de cette boucle nécessite une stratégie que seul le politique est apte à proposer. Or le politique est lui aussi embourbé dans les conséquences de la mort du Progrès.

La putréfaction sécuritaire du politique

Le clivage droite-gauche est devenu illisible, faute de clivage fort, nous dit l’auteur. Plus rien ne distingue la gauche de la droite : cette dernière s’est complètement ralliée à l’idée de Progrès, au système capitaliste, à la République et à la laïcité. Seuls les extrêmes tirent leur épingle du jeu, en gardant des bribes des clivages qui, autrefois, définissaient la gauche et la droite.

Second constat : un certain malaise démocratique. L’auteur dresse un tableau quasi-maurrassien de la république actuelle : les politiques sont impuissants, ils ne représentent personne ; les français sont désunis par une guerre permanente entre les partis ; les luttes partisanes obligent à prendre des positions radicales au détriment des nuances constructives ; la moindre prise de position hétérodoxe change le débat en Procès de Moscou ; l’électoralisme pousse les dirigeants politiques au cynisme ; il n’y a plus de chef d’État à la tête du pays mais un chef de parti ; des élites (pays légal) dirigent un peuple (pays réel) sans avoir aucune idée de ses préoccupations ; les élections interdisent toute projection dans le temps long, pourtant apanage du politique.

Bref, le politique en France est bien malade. Les maux qui l’accablent ont l’effet dévastateur d’ôter tout espoir à un peuple déjà abattu par la mort du Progrès. La société devient encore plus inquiète et craint des temps difficiles. De telles périodes dans l’histoire ont toujours fait émerger des boucs émissaires, des ennemis de l’intérieur qu’il convient de traquer.

Il n’y a pas d’idéologie sécuritaire soutient Éric Delbecque. La société de surveillance n’est que le miroir de notre propre méfiance collective. Les mêmes causes à une époque technologiquement moins avancée avaient provoqué la chasse aux sorcières, folie collective où de petits juges laïcs brûlaient les malheureuses désignées comme boucs émissaires. Aujourd’hui la société a remplacé le bûcher ponctuel par des caméras omniprésentes. Tout le monde est suspect, tout le monde doit être surveillé.

Retrouver du sens ?

L’auteur appelle les sociétés occidentales, la France en particulier, à retrouver du sens grâce à un projet fédérateur. A la fin de cet essai fortement influencé par les non-conformistes des années 30 (Mounier, Maulnier, Aron), plus particulièrement par la Jeune Droite, l’auteur appelle la France au relèvement. Il ne souhaite pas plus le retour du progressisme béat, appelé par Michéa « Complexe d’Orphée », que celui d’un conservatisme poussiéreux comme le XIXème en eût le secret.

Éric Delbecque souhaite l’avènement d’une troisième voie, entre progressisme et conservatisme, un système politique capable d’avancer, sans pour autant se précipiter. Un système ayant les reins assez solides pour prendre son temps. Il souhaite surtout un souffle, un projet national capable de fédérer les Français et de les sortir de la dépression nationale.

L’auteur ne précise hélas pas quel pourrait être un tel système, ce qui pourrait être un excellent sujet pour un prochain ouvrage. Vu la pertinence de celui-ci, nous l’attendons avec impatience.

L'argent est mis sous surveillance

Tue, 08 Mar 2016 00:00:00 +0000

Toujours dans le but de préserver nos libertés et de lutter contre le terrorisme, le gouvernement Valls étend l’empire de la surveillance informatisée, en éliminant ce qui ne l’est pas. Bercy a récemment proposé d’éliminer progressivement l’argent liquide, rendu obsolète par les moyens de paiement électroniques. On accuse pièces et billets de faciliter le blanchiment et le financement du terrorisme. Les banquiers de Guernesey ou des Bahamas doivent bien s’esclaffer …

Ellul prédisait dans les années 60 une Technique totalisante, ne pouvant cohabiter avec les systèmes traditionnels. Déjà, en 1985 l’état interdisait le paiement des salaires en espèces : le passage par la banque devenait obligatoire. Les 30 années qui ont suivi ont vu les prélèvements à la source augmenter, au détriment de l’acte volontaire du paiement des impôts. Aujourd’hui le nouvel ordre mondial veut imposer le monopole de moyens de paiement liberticides, au nom de la moraline, de la sécurité ou encore de l’efficacité. Dormez braves gens l’état vous protège des méchants.

La levée des impôts, véritable confrontation du pays légal et du pays réel à toutes les époques, se change en simple tonte : automatique, indolore et obligatoire. La banque se fait l’intermédiaire de cette spoliation qui remplace le collecteur d’impôts d’autrefois. Le consentement à l’impôt, inscrit dans la Déclaration des droits de l’homme et du citoyen de 1789, prétendait combattre l’arbitraire de l’impôt royal. Deux siècles plus tard, la République achève la supercherie : là où le roi devait affronter physiquement les contribuables mécontents, l’état moderne peut les ignorer et lever l’impôt sans demander l‘avis de personne.

Quel progrès !

OS Souverain : une annonce irréaliste

Wed, 20 Jan 2016 00:00:00 +0000

Dans le cadre du projet de loi République Numérique et sur proposition de Delphine Batho, les députés ont voté en commission la création d’un Commissariat à la souveraineté numérique qui aurait la responsabilité de créer un système d’exploitation français.

L’idée part d’une bonne intention : garantir la souveraineté numérique du pays. L’affaire Snowden a révélé les liens étroits entre Microsoft et la NSA américaine : il n’est pas paranoïaque de se méfier de Windows d’autant que son code source est fermé donc potentiellement bourré de portes dérobées.

La proposition de Delphine Batho n’est pas sans poser de problèmes. Quid de la faisabilité d’un tel projet ? Un système d’exploitation moderne représente des centaines de milliers d’heures de travail pour arriver à une version fonctionnelle. Si ce projet aurait l’avantage de créer de l’emploi, il coûterait cher à un état déjà endetté. Une solution européenne serait peut-être plus réaliste mais a-t-elle un avenir ? Le marché des OS est déjà saturé, entre Microsoft, Apple et Linux.

Linux d’ailleurs correspond parfaitement au cahier des charges d’un OS souverain, si par souverain la députée ne sous-entend pas « sous contrôle étatique ». Rappelons une règle d’or de la sécurité : la protection doit être proportionnelle à la menace. L’OS est libre donc auditable par tous. Il est aujourd’hui compatible avec la plupart des matériels et sa réputation d’être peu ergonomique est largement dépassée. La seule chose qui manque au monde Linux est un portage de beaucoup d’applications grand public. Ce portage n’intéresse pas les éditeurs de logiciels à cause de la faible utilisation de Linux. Là où Linux échoue avec ses milliers de contributeurs, un système franco-français ne peut pas réussir.

Pour les utilisateurs les plus exigeants en termes de sécurité, l’ANSSI, véritable chien de garde numérique de l’état français a sorti son propre OS : CLIP.

Cet OS est habilité pour le traitement d’informations classifiées très secret défense, grâce à un système de caissons séparant les applications. Il ne s’agit en revanche pas d’un OS grand public, sa lenteur le lui interdit.

Peut-être que si les élus français n’avaient pas pris l’habitude de balayer d’un revers de main les recommandations de l’ANSSI, qui conseille Linux, ainsi que moult autres solutions de sécurisation grand public, ils ne seraient pas passés pour des ânes une fois encore. Cette proposition d’OS souverain n’est pas pertinente : la sécurité numérique du grand public comme celle des plus hautes sphères de l’état peut se satisfaire des solutions existantes.

Inciter les éditeurs français à porter leurs applications sous Linux et promouvoir ces OS auprès des français aurait été une stratégie bien plus réaliste.

Qu'est-ce que l'uberisation ?

Tue, 05 Jan 2016 00:00:00 +0000

On désigne par Uberisation l’attaque frontale des marchés de services par de nouveaux acteurs utilisant à leur avantage les possibilités du numérique. Le mot vient d’Uber, nom d’une ambitieuse entreprise américaine, qui a l’ambition de payer des particuliers pour transporter tout ce qui peut l’être en milieu urbain. Uber a créé le buzz en affrontant les taxis, profession traditionnelle assurant le transport de personnes. Ces frictions mondiales et bien souvent violentes ont fait une immense publicité pour l’entreprise.

Un phénomène global post-salarial

Les taxis ne sont pas les seuls menacés par des entreprises de type Uber. L’uberisation concerne tous les secteurs des services : graphistes, avocats, hôtels, banques, etc.
L’uberisation est une disruption qui concerne toutes les professions de services, d’une intensité égale à l’arrivée des machines dans l’industrie. Le travail de management est confié à des algorithmes qui désormais font le lien entre le top management et les « exécutants ». Nous appelons volontairement les personnes en bas de la hiérarchie « exécutants » car ceux-ci ne sont plus des salariés, mais des indépendants, voire des particuliers lorsque la législation le permet (UberPOP).

Pour autant a-t-on atteint le rêve marxiste d’un producteur autonome ? Absolument pas.

La nature du lien entre l’entreprise et le travailleur est changée, de la même manière que le salariat la changea par le passé. Nous étions à l’ère préindustrielle sur un tissu organique d’entreprises artisanales décentralisées. La révolution industrielle a brisé les corporations et fait du salariat la norme, le modèle entrepreneurial et devenu un modèle hiérarchique. L’automatisation croissante, allant avec le numérique jusqu’aux tâches managériales, permet l’émergence d’un modèle mécanique. Celui-ci consiste en un donneur d’ordres, commandant par machines interposées une myriade d’individus avec lesquelles il n’a aucune relation humaine. Ces individus n’ont aucune compétence particulière et sont comme des caractères d’imprimerie, spécialisés mais interchangeables.

Le lien juridique entre le donneur d’ordres et l’exécutant est différent du lien salarial. Le lien salarial est un lien fort, impliquant une certaine responsabilité de l’entreprise pour les actes de son salarié. Le salariat implique également un partage des risques de l’activité entre le salarié et l’entreprise.

Dans le système uberisé, le donneur d’ordre partage les bénéfices mais peu les risques. Chez Uber par exemple, la voiture est la propriété du conducteur qui doit l’assurer en son nom propre. En cas d’accident, l’entreprise ne participera aucunement aux frais de réparation.
S’il n’y a pas de lien salarial, il n’y a pas de licenciement. Radier un conducteur chez Uber revient à ôter une ligne dans une base de données, sans possibilité de recours pour l’exécutant. Les conditions de la sécurité de l’emploi ne sont plus assurées.
A l’inverse, l’exécutant n’est plus obligé de travailler pour un seul employeur. Il peut tirer une partie de sa subsistance de chaque employeur pour lequel il travaille. Nous assistons à une mercenarisation de l’économie, où l’employeur n’est plus obligé d’assurer seul un salaire permettant la subsistance de ses subordonnés, car le subordonné est libre de travailler pour plusieurs employeurs.

Le rapport de forces social entre le producteur et le consommateur, déjà défavorable depuis la fin des corps intermédiaires, penche définitivement en faveur d’un client-roi, bien content de l’uberisation des professions autres que la sienne.

La stratégie d’uberisation

La stratégie de ces entreprises est grossière mais diablement efficace car elle exploite les faiblesses de la division des pouvoirs en démocratie. Il s’agit d’une stratégie cyclique, visant à faire du business dans un intervalle de temps délimité par l’arrivée de l’entreprise dans un secteur et l’application réelle de la nouvelle réglementation. A la fin de chaque cycle, l’entreprise parie sur l’innovation pour changer de créneau et ainsi esquiver perpétuellement la loi.
L’appareil étatique est ainsi toujours en position de réaction face à une entreprise qui crée ses propres marchés. L’enjeu pour l’entreprise est de faire durer le plus longtemps possible cette posture de réaction de l’état. La tactique de ces entreprises est toujours grossièrement la même : exploiter les failles des régimes parlementaires. Nous pouvons observer quatre phase dans chaque cycle, chacune correspondant à l’un des quatre pouvoirs des démocraties modernes :

Phase médiatique : conquête d’une opinion ou, pour un secteur donné, les gens de métier lésés sont en minorité face à la masse des consommateurs. Ces consommateurs, en majorité des employés du tertiaire sont incapables de penser que demain, l’uberisation touchera certainement leur secteur.
Désobéissance face à l’exécutif : l’entreprise entre sur le marché, pariant sur l’incapacité de l’exécutif à prendre une décision, faute de légitimité. L’exécutif, tenu par un parti, est très souvent moins populaire que l’entreprise. Sans loi, votée par le parlement, le gouvernement n’agira pas pour ne pas risquer de s’attirer les foudres des électeurs.
Les corps constitués et les entreprises traditionnelles ne peuvent pas se battre, à cause du flou juridique.
Lobbying législatif : Une fois l’affaire arrivée aux chambres, l’entreprise utilise les affrontements entre partis (souvent entre sociaux-démocrates et libéraux) pour ralentir le processus législatif. Les majorités absolues étant rares, le texte de loi doit être consensuel et inoffensif pour passer au vote. L’entreprise se débrouille pour neutraliser les articles les plus dangereux.
Blocage judiciaire : Lorsque la loi, même consensuelle et molle, est passée, l’entreprise commence à la contester en utilisant tous les recours administratifs et juridiques possibles. En France, Uber a utilisé les Questions Prioritaires de Constitutionnalité (QPC), les recours au Conseil d’État, etc…
Le but n’est pas de gagner, mais de faire perdurer l’activité controversée le plus longtemps possible. Cette phase peut durer de nombreuses années, le labyrinthe judiciaire de certains pays étant particulièrement vaste.

Chaque nouvelle phase vient s’ajouter aux précédentes et ne les remplace pas. Une fois la loi votée, l’entreprise continue son lobbying, notamment pour faire voter des législations contradictoires, abrogatives ou inapplicables. La guerre médiatique est permanente afin de maintenir la pression sur l’état : hors des projecteurs, de telles entreprises pourraient être balayées par décret ou par simple répression policière.

Tous ces efforts n’ont qu’un but : gripper la machine d’état suffisamment longtemps pour permettre à l’entreprise de sauter dans le wagon suivant du train de l’innovation, laissant gouvernant et procureurs en arrière.

Les systèmes législatifs, dont l’impératif est d’assurer un cadre légal stable, donc lent à évoluer, ne suivent pas face à «la nature supranationale de l’Internet sur l’enchevêtrement des lois et réglementations qui entravent l’innovation» (sic).

Pour aller plus loin

COORNAERT Emile – Les corporations en France avant 1789

BERGER Claude – En finir avec le salariat, pour une société du partage

Fallout 4 : Le jeu vidéo dans la guerre des idées

Tue, 08 Dec 2015 00:00:00 +0000

Sorti le 10 novembre, Fallout 4 marque un tournant dans l’histoire d’une série déjà mythique. Bethesda vient de prouver sa capacité à proposer un jeu qui ne se résume pas à une quête linéaire aboutissant sur un happy end à l’américaine. Fallout 3 en avait déçu plus d’un, Fallout : New Vegas avait un peu rattrapé le tir, Bethesda n’avait pas le droit à l’erreur sur ce nouvel opus.

Pour ceux qui ne connaissent pas la série, Fallout met en scène l’immersion d’un personnage sans talents particuliers dans un monde annihilé par une guerre nucléaire. L’humanité a survécu en se réfugiant dans des abris le temps de la catastrophe. Des groupes humains se battent sur les ruines des Etats-Unis, les sinistres « Terres Désolées », certains pour le pouvoir et l’argent, d’autres pour des buts plus nobles. Dans ce quatrième opus, le joueur incarne un personnage qui fut cryogénisé avec sa famille le jour où les bombes tombèrent.

L’histoire se déroule autour de ce qui fut Boston. Les habitants sont terrorisés par le croquemitaine local : l’Institut. Ce centre de recherches souterrain, héritier du MIT, n’hésite pas à kidnapper et à tuer pour faire avancer la science, seul espoir de l’humanité selon eux. Le personnage, cheminant pour retrouver son fils kidnappé va se retrouver obligé de prendre position pour ou contre l’Institut, qui ne manque pas d’ennemis. Contre ces dangereux scientistes on retrouve la Confrérie de l’Acier, armée technophobe se donnant la mission de protéger l’humanité contre elle-même, quitte à utiliser de la technologie de pointe pour cela. On retrouve également le Réseau du Rail, un mouvement d’affranchissement des intelligences artificielles, qui dénonce l’esclavage des machines par leurs créateurs. Enfin il y a les Miliciens, une milice en ruines que le joueur pourra reconstituer et utiliser comme il le souhaite. Les factions en présence ont un discours bien plus construit que dans les précédents opus. Le manichéisme de Fallout 3 a disparu pour placer le joueur face à des dilemmes. Aider une faction aura forcément des conséquences sur les autres, il n’est pas possible d’échapper au tragique.

Fallout 4 est bien plus amer, dramatique et réaliste que ces prédécesseurs. Il témoigne d’un véritable travail de recherche des scénaristes, afin de donner des discours crédibles à des factions autrefois trop manichéennes. Contrairement à ce que l’on pourrait attendre, il n’y a pas de favoritisme dans un sens où l’autre.

Cette oeuvre prouve qu’il est possible d’utiliser le medium vidéoludique pour traiter de sujet sérieux tout en divertissant le public. Le jeu vidéo utilise le principe de storytelling pour transmettre des messages aux joueurs. Le format RPG (Role Playing Game, jeu de rôles) s’y prête particulièrement bien, le joueur a l’impression de construire lui-même son histoire dans un monde aux contours dessinés par l’éditeur. L’engagement du joueur dans le jeu est décuplé par rapport à ce qu’un auteur peut attendre sur un article ou une vidéo. Le joueur se prend au jeu, y fait des choix en accord avec le personnage qu’il veut jouer et les conséquences de ces choix, apparemment logiques, lui sont en réalité imposées par l’éditeur, qui y fait passer son message en jouant sur le vraisembable.
Le potentiel des jeux vidéo pour la propagande commence juste à être compris par quelques éditeurs comme Square Enix ou bien Bethesda. Ce qui était pour l’instant un excellent outil marketing pourrait bien devenir dans les prochaines années une nouvelle arme dans la guerre des cerveaux.

Dans le monde réel comme dans les Terres désolées de Fallout, hélas :

War, war never changes.

Indispensables corporations

Tue, 03 Nov 2015 00:00:00 +0000

Costume-cravate, honnêteté, politesse : il devient compliqué de reconnaître nos chers taxis parisiens ! Quel dommage qu’il faille une agressive entreprise étrangère pour que la profession se remette en cause. Que de temps perdu, d’argent gâché et de drames pour arriver à un résultat qui n’est somme toute que le simple bien commun.

Avant la crise, personne n’a voulu voir le problème, pendant la crise, personne n’a voulu le traiter efficacement, après la crise, personne n’a eu la folle idée de se remettre en question. Ni l’état ventripotent, ni les entreprises mues par le profit, ni les fédérations oligarchiques, ni les syndicats borgnes n’avaient les cartes pour agir. Chacun a ses intérêts propres, s’affrontant par-ci, se recoupant par-là, mais aucune n’a l’intérêt de la branche pour boussole.

L’intérêt de la branche est l’intérêt commun des acteurs physiques de cette branche, sur le long terme. Ils ne sont pas défendus et ce manque est une des faiblesses de notre économie. Désunis, les français sont à la merci de l’étranger, l’affaire Uber le montre. La défense économique d’une branche requiert d’abord l’union interne.
L’union interne requiert de rassembler autour d’une tables toutes les personnes physiques d’une branche : ce que l’on nommait jadis une corporation.

Il ne s’agit pas de ressusciter les institutions aujourd’hui dépassées du XVIIIème siècle. Il s’agit d’en reprendre l’essence afin de créer des corps intermédiaires adaptés au XXIème siècle. Aucun autre type de corps ne peut défendre le métier aussi bien que la corporation. Aucun autre type de corps n’est légitime pour juger les professionnels peu consciencieux. Aucun autre type de corps n’est compétent pour règlementer le métier.

L’état est bien trop éloigné des considérations des métiers pour être légitime à les gouverner. Il ne doit pas se disperser s’il veut exceller dans le régalien, qui n’est pas contingent. Or l’état français fait tout l’inverse : il s’immisce pour des raisons électoralistes dans les affaires courantes des branches professionnelles au détriment du régalien. La loi devient une rustine sur un pneu déjà trop chargé.
Les entreprises n’ont en aucun cas l’intérêt de la branche pour boussole. Leur but est le profit, qui parfois passe par des licenciements ou par une guerre avec la concurrence nuisible au métier. La règlementation du lobbying fait entendre la voix du plus riche, au détriment de la majorité silencieuse.
Les syndicats sont chargés de défendre le patronat ou le salariat, dont les intérêts sont parfois contraires à l’intérêt commun des deux. La négociation entre syndicats patronaux et salariaux prend une forme de bras de fer, faute d’arbitre.

Chacun de ses corps existe et a son utilité, mais il manque un corps rassemblant les professionnels eux-mêmes, dans leur diversité et leur unité. Il manque un corps qui mette autour d’une table à égalité les employeurs, les employés, les indépendants et toute personne exerçant effectivement un métier. Or depuis la Révolution Française, de tels corps sont interdits par des lois liberticides, au motif qu’ils entravent la libre-concurrence. Le droit de mal travailler, au détriment du client est une réalité. Le droit des gens de métier à se gouverner eux-mêmes est sacrifié sur l’autel d’une idéologie du marché et de la libre-concurrence fantasmagorique.

Les gens de métier ont le droit de se gouverner eux-mêmes. Malgré la loi, vive le pays réel, vive les ordres professionnels et vive les corporations !

Les suites de l'affaire Uber

Mon, 02 Nov 2015 00:00:00 +0000

Avec quelques mois de recul, il nous semble intéressant de revenir sur Uber. Cette société avait provoqué l’ire des taxis français en lançant son service UberPOP, qui remplaçait des VTC professionnels par des chauffeurs particuliers.

La défaite d’Uber suite à l’interdiction d’UberPOP n’a été que relative. L’entreprise est revenue en force en Europe et compte bien étendre son modèle apparemment décentralisé à tout ce que l’on peut transporter en voiture. Face à cela, les acteurs existants sur les marchés traditionnels sont mal préparés. Les outils classiques de veille concurrentielle et de défense d’intérêts économiques ne suffisent plus. L’État, qui s’est lancé dans la bataille, ressemble de plus en plus au puissant éléphant, incapable de stopper la souris, trop rapide pour lui.

Uber, pieuvre logistique urbaine

La stratégie d’Uber est claire : absorber tout flux urbain d’hommes ou de marchandises pouvant être transporté par des voitures. Ils se voient eux-mêmes comme un réseau logistique urbain. À leur activité traditionnelle de transport de personnes, viennent s’ajouter le transport de repas avec UberEATS et transport de colis avec UbeRUSH, les médicaments avec UberHEALTH voire même … les chatons avec l’éphémère UberKITTENS.

En l’absence de réaction rapide, les métiers de livreur et de coursier risquent de connaître le même sort que les taxis. Encore faudrait-il, pour qu’il y ait réaction, que ces professions soient au courant des manœuvres offensives d’Uber. Or une veille concurrentielle « classique » ne permet pas de détecter cela. Celle-ci ne cible que les marchés sur lesquels l’entreprise est déjà implantée, en aucun cas de nouveaux marchés capables de phagocyter les anciens. La sape d’un marché existant par un nouveau est désormais désignée par le terme « uberisation ».

Même les régies de transport urbain, comme la RATP par exemple, ne sont pas à l’abri de bouleversements. Uber compte bien remplacer les bus par des « Smart Routes », fragmentation d’un bus en des dizaines de véhicules de tourisme circulant sur une ligne précise. En changeant simplement une organisation existante (les VTC Uber), un nouveau marché s’ouvre à l’ambitieuse entreprise, sans qu’ils ne soient pour autant présent sur le même marché que la RATP.

Uber s’en va en guerre … économique

Uber s’est donné les moyens de ses ambitions par le rachat d’une grande partie de Bing Carto, le service de cartographie de Microsoft. Uber fut un temps candidat à l’acquisition de Nokia Here, également entreprise de cartographie. Les brevets et le savoir-faire de ces entreprises sont précieux à Uber qui souhaite optimiser au maximum chaque trajet. Ces rachats s’inscrivent dans une guerre à l’innovation qui fait rage entre Uber et Amazon. En effet, le géant de la logistique cherche lui-aussi à conquérir le marché de la livraison de paquets par véhicules légers. UberRUSH et Amazon Flex se situent exactement sur le même marché, avec néanmoins des axes d’innovation différents. Tandis qu’Uber mise sur les voitures sans chauffeur, Amazon innove avec des drones-coursiers.

L’entreprise investit beaucoup dans la recherche, son partenariat de 5.5M$ avec l’université de Carnegie-Mellon vise avant tout à créer ses propres véhicules autonomes. Au-delà du partenariat, Uber n’hésite pas à débaucher des scientifiques de Carnegie-Mellon pour son centre de Pittsburgh, à coup de centaines de milliers de dollars. Avec des partenaires comme Uber, pas besoin d’ennemis.

Le marché naissant du transport par véhicules personnels est trop juteux pour ne pas attirer les convoitises. Nous avons déjà parlé d’Amazon, mais ils ne sont pas les seuls à vouloir dominer ce marché.

Il y a d’abord Lyft, ambitieuse startup qui se verrait bien calife à la place du calife. Cela ne semble pas gagné d’avance, Lyft ne propose rien d’innovant par rapport à Uber et ne se positionne pas pour l’instant à l’international. Lyft ne fait en outre que du transport de personnes. Uber fait tout pour les handicaper, y compris des actes qui pourraient être qualifiés de déloyaux, comme de fausses réservations.

Il y a ensuite Daimler-Mercedes, un cas bien plus intéressant car Mercedes possède déjà une forte base de brevets concernant les véhicules sans conducteur (voitures, bus et camions). Daimler compte bien créer son propre service de transport de personnes pour concurrencer Uber, avec des voitures sans conducteurs.

Enfin, le plus intéressant, Google. Le conglomérat pourrait bien avoir joué les Cronos en investissant dans Uber, alors une petite startup, 258 millions de Dollars. Avec l’objectif de créer des débouchés pour sa Google Car, Google pensait trouver en Uber un allié intéressant. Désormais Uber envahit de plus en plus de secteurs sur lesquels Google a des vues. Réseaux de transport urbain, cartographie, voitures autonomes, Uber devient gênant pour Google. Une guerre couve.

Ces frictions entre Uber et ses concurrents actuels ou potentiels ne s’arrêtent pas aux portes des Etats-Unis et de l’Europe. Uber annonce déjà avoir 30% de parts de marché en Chine, où Lyft a conclu un partenariat avec Didi Kuaidi, un opérateur local. Uber est également présent en Amérique du Sud, en Russie, en Inde, en Afrique du Sud et dans de nombreux autres pays.

La France bouge ?

Revenons en France où « l’affaire Uber » a fait grand bruit. Une résistance s’est spontanément organisée, désespérée au début avec les blocus effectués par les taxis. Une chronologie des faits a déjà été réalisée par l’Observatoire Taxi/VTC de l’Ecole de Guerre Economique, nous passons directement à l’analyse.

Premier constat, l’État n’a jamais eu de ligne claire sur le sujet. On note un manque total de ligne stratégique du gouvernement et de l’assemblée. La stratégie de la feuille morte semble avoir été privilégiée : aller immédiatement et sans réfléchir dans le sens du vent. Grève des taxis ? Il faut réglementer les VTC. Lobbying ou poussée de l’opinion en faveur des VTC ? Suspendons ces lois liberticides !
Même lorsque l’État tente de prendre position, il le fait toujours avec une guerre de retard. Les contrôles « renforcés » se sont montrés globalement inutiles face à Uber. Lorsque les lois n’étaient pas inapplicables (« maraude électronique », stationnement, accès aux voies réservées bus …) ce furent des particuliers enrôlés dans UberPOP qui essuyaient les coups. Les Boers (police des taxis), en nombre insuffisant n’ont pas été efficaces, même avec le secours d’agents de la Direction générale de la concurrence, de la consommation et de la répression des fraudes (DGCCRF) déjà bien occupés.

Les juristes d’Uber ont joué à l’éléphant et la souris avec l’État. Aussitôt UberPOP interdit, Uber s’est sagement rangé comme prestataire classique de VTC. Ils sont revenus à la charge en procédant à un véritable hacking législatif : pour contourner la France drastique des VTC, ils ont utilisé le statut de capacitaire LOTI, utilisé normalement pour le transport collectif de personnes.

Ce statut LOTI est cumulable avec la profession de Taxi, mais pas avec le statut de VTC. Qu’à cela ne tienne ! Chez Uber les deux statuts sont complémentaires, environ 40% de LOTI et 60% de VTC qui répondent selon les besoins du client, contournant les limitations propres à chacun des statuts. Uber serait même en train de débaucher des taxis pour combler les besoins résiduels auxquels ni LOTI ni VTC ne peuvent répondre.

Bien entendu, le grand public n’a pas vent de ces affrontements. Uber a effectué un impressionnant service de relations publiques afin d’avoir des soutiens de poids dans l’opinion. Sa campagne visait avant tout les yuccies. Les taxis urbains ne sont pas blancs comme neige et une vaste campagne de déstabilisation a achevé de leur donner mauvaise presse. Préjugés antipathiques et malhonnêtes, les taxis sont tombés tout droit dans le piège des grèves violentes, détruisant durablement leur image auprès du public cible d’Uber : les jeunes urbains et les cadres.
Ce public cible est important dans la stratégie d’Uber. L’entreprise compte bien peser sur le législateur par diverses pétitions en ligne.

Chez les taxis, peu de choses ont réellement bougé. La profession peine à trouver d’autres arguments contre Uber que la défense de l’emploi (qu’Uber met aussi en avance avec plus de visibilité). Il serait plus intéressant pour les taxis d’appuyer sur le montage fiscal d’Uber, ou la baisse artificielle des prix déjà utilisée comme arme contre Lyft.

Quelques initiatives intéressantes des taxis ont tout de même attiré notre attention :

Le Tumblr J’aime les VTC, qui recense des tweets de clients mécontents des VTC
L’initiative de l’association Les Nouveaux Taxis Parisiens (LNTP) qui, au lendemain des manifestations du 25 juin, ont pris l’initiative de taxis gratuits. L’échec de l’initiative vient surtout de sa sous-médiatisation.
L’application le.taxi qui propose de géolocaliser et de héler un taxi aussi facilement qu’un VTC.

Chez les VTC, Uber arrange et dérange. Lorsqu’ils attirent sur eux les projecteurs et permettent aux autres compagnies de VTC de travailler hors des caméras inquisitrices, Uber est apprécié par les acteurs français. Zipcar, BlablaCar, Heetch, MaPool ou bien Drivy n’ont pas fait la une des médias, ils sont pourtant eux aussi des acteurs majeurs du VTC en France.
Uber arrange également car il est facile dans le monde numérique de « forker » un projet. VTC Cab, nouvel acteur du VTC français s’est monté à partir d’une scission d’Uber France, les chauffeurs ayant développé leur propre application.
En revanche, Uber dérange par son agressivité qui ne s’arrête pas aux taxis. La société vise l’hégémonie en se plaçant sur toutes les gammes, du low-cost au luxe, en passant par le professionnel. Pour cela tous les moyens sont permis, y compris ceux que la morale admise s’interdit … contrairement aux dures lois du marché. La concurrence tranquille entre acteurs respectant tacitement des règles communes est de plus en plus dépassée et la naïveté des acteurs traditionnels pourrait leur être fatale.

Néanmoins, les VTC ont la volonté de s’organiser de manière efficace. Il est rare, en France, qu’une profession décide spontanément de mettre patrons et salariés autour d’une table, le poids d’un certain esprit syndical voudrait bien voir le fantôme du corporatisme rester au tombeau. L’affaire est à suivre, il se pourrait que face à l’ennemi désigné qu’est Uber, toute une branche organise sa défense de manière unie. CAPA-VTC ambitionne de rassembler à la fois les capacitaires LOTI (donc les taxis ?) et les VTC, patrons et salariés confondus, sous une même bannière. L’association est jeune mais prometteuse, affaire à suivre.

Une inconnue reste : Comment évolue le marché des taxis clandestins ? Avec une législation de plus en plus restrictive, des boers de plus en plus débordés et un marché de plus en plus juteux, nous pensons légitime de nous poser la question. On estimait en 2013 le nombre de taxis clandestins parisiens à 300, le chiffre 2014, qui sera prochainement publié par la Préfecture de Police de Paris pourrait être intéressant.

L’Intelligence économique à la rescousse

Le numérique a redistribué les cartes dans une profession ancienne. L’innovation technologique a rapidement permis à des sociétés ambitieuses de casser les vielles règles au profit de nouveaux modèles qui se disent décentralisés.

L’armement utilisé pour la guerre économique a lui aussi évolué, ce que nous appelons le « fork d’entreprise » en est un exemple. Les entreprises américaines ont une véritable culture du combat économique dont nous manquons cruellement, Uber en témoigne. L’entreprise a su utiliser avec brio les cartes qui lui étaient données. Elle a su exploiter les contradictions du système politique français, les trous de notre législation, les erreurs des taxis, les affrontements en cours avec les VTC. Elle a su charmer des portions clés de l’opinion, pousser des tiers à lui servir de bouclier, etc. Sun Tzu aurait applaudi.

En face, un vide stratégique et des acteurs qui n’ont pensé à s’unir qu’après la bataille. Taxis et VTC français n’ont pas eu de meilleure idée qu’une mêlée générale pendant qu’une entreprise étrangère attaquait. Pourtant les armes existent pour qui souhaite s’en saisir. L’intelligence économique en promouvant une utilisation intégrale des sources ouvertes qui ne se limite pas à la veille concurrentielle classique aurait pu permettre au monde du transport de personnes français d’anticiper Uber. Mieux, l’IE aurait pu permettre de comprendre et donc de combattre les manœuvres d’Uber sus-listées. Rien n’a été démarré, ni l’État, ni les corps intermédiaires, ni les entreprises n’ont vu venir l’innovation et ceux qui allaient l’utiliser contre eux.

Il ne faut pas pour autant désespérer. Des coalitions s’organisent qui, si elles arrivent à mettre en place une véritable stratégie, pourront survivre. Uber ne s’en cache pas, Mercedes non plus : la voiture sans conducteur est sur les rails, les taxis et VTC ont intérêt à se réinventer pour survivre. L’IE est une nécessité, même le plus inventif ne peut rien s’il est aveugle.

Article initialement publié sur le portail de l’IE.

Compte-rendu de la conférence : Pourquoi la puissance ?

Mon, 12 Oct 2015 00:00:00 +0000

Vendredi 9 octobre dernier, l’École de Guerre Économique et la revue Conflits démarraient un cycle de conférences sur la puissance. Le premier volet avait pour problématique « Pourquoi la Puissance ? ». L’intervenant, Gérard Chaliand est un géo-stratège, spécialiste de la guérilla et du terrorisme. Il nous a livré son analyse des grands conflits géopolitiques actuels, tout en gardant la puissance comme fil rouge. Résumé.

Puissance est un mot tabou dans le vocabulaire français. Sous prétexte que certains en ont abusé par le passé, nous serions condamnés, tels des feuilles mortes, à nous laisser emporter par le vent ! Car c’est bien de cela qu’il s’agit. Pendant que la France détruit sa puissance, d’autres font usage de la leur et abusent de notre faiblesse pour faire primer leurs intérêts chez nous. Perdre son rang parmi les puissances n’est pas anodin, un peuple qui refuse d’être puissant est condamné à perdre son influence puis à voir sa population s’appauvrir – en attendant la servitude.

L’Histoire regorge de puissances déclinantes, ayant perdu toute influence jusque chez elles. La Perse, la Chine, l’Inde ou la Turquie ne sont pas des émergents mais bien de ré-émergents, souligne le conférencier. La puissance n’est pas l’apanage des grands, qui peuvent être gênés ou rattrapés par de plus petits ensembles. La pugnacité compte plus que la taille disait le stratège hindou Kautilya, auteur du traité Arthashastra.

Aujourd’hui la France doit retrouver sa puissance, non seulement pour mettre fin au règne de l’étranger, mais également pour combattre la finance apatride, qui se verrait bien Calife à la place du Calife, décidant même de ce qui est souverain. L’intervenant a clos son propos en égrenant une liste de blocages imputables au calendrier politique : Obama prisonnier de ses promesses électorales sur la Syrie ou Hollande incapable d’assumer une guerre auprès de son électorat. Décidément, la démocratie a du mal avec la puissance : Les échéances électorales agissent comme un couperet sur une politique étrangère déjà bien falote.

La prochaine conférence du cycle « Puissance 21 » aura pour problématique « Qui détient la puissance dans le monde ? » par Pascal Gauchon, directeur de la revue Conflits. Plus d’informations sur le site de l’École de Guerre Économique (ege.fr).

A rational design process: How and why to fake it

Fri, 05 Jun 2015 00:00:00 +0000

🧮 Errare humanum est, dit la locution. Les auteurs ne croyaient déjà pas à la possibilité d’une méthode formelle de développement logiciel en 1986. Nous ne seront jamais des mathématiciens déduisant un théorème à partir d’axiomes, car si le logiciel est écrit dans un langage strict, son objet est ô combien humain.

📚 Parnas et Clements soutiennent cependant l’utilité de feindre la rationalité, autrement dit de produire au cours du projet la même qualité de documentation que celle qui aurait été nécessaire pour produire un logiciel valide du premier coup. C’est un effort substantiel, mais payant selon eux.

📑 Quelles sont les propriétés d’une bonne documentation ? Elle est organisée hiérarchiquement afin d’optimiser la recherche d’informations, non l’écriture. Elle contient le moins possible de prose, remplacée par des diagrammes, schémas, formules, etc. Elle est complète et ne contient qu’une seule fois chaque information. Elle utilise des espaces de noms pour éviter la confusion de termes équivoques.

✅ Toutes ces propriétés se retrouveront 20 ans plus tard dans les recommandations pour écrire de bons tests d’acceptation : il n’y a pas de mystère, un test d’acceptation n’est pas autre chose qu’une documentation exécutable.

SOURCE

David Lorge Parnas and Paul C. Clements. 2001. A rational design process: how and why to fake it. Software fundamentals: collected papers by David L. Parnas. Addison-Wesley Longman Publishing Co., Inc., USA, 355–368. DOI:10.1109/TSE.1986.6312940

Loi Renseignement : Gare à la surinfection !

Fri, 01 May 2015 00:00:00 +0000

Doit être votée le 5 mai prochain par l’Assemblée nationale la loi dite « Renseignement ».
Cette loi est décrite par le gouvernement comme une modernisation des moyens de lutte contre le terrorisme, en particulier sur Internet. La loi prévoit de passer sous décision administrative des moyens d’espionnage pour l’instant utilisés de manière parcimonieuse et sous contrôle du juge : micros, caméras ou « boîtes noires » placées chez les fournisseurs d’accès. Le but avoué par le gouvernement est une plus grande réactivité dans la lutte antiterroriste, le juge étant vu comme beaucoup trop prudent en matière de surveillance.

Cette loi ne prévoit aucune possibilité de recours en cas d’abus. Elle prévoit une vague commission de contrôle au rôle uniquement consultatif.
Les réactions ne se sont pas faites attendre : la loi a cristallisé les oppositions, l’opinion sentant instinctivement le danger. Cette fois-ci, le vieil argument « si vous n’avez rien à cacher vous n’avez rien à craindre » n’a pas suffi à faire taire la société civile, ainsi que les quelques courageux du monde judiciaire qui ont élevé la voix. Le monde politique, exceptés le PS et une partie de l’UMP, ont été unanimes à condamner ce projet de loi.

Comme d’ordinaire lorsque l’on touche à Internet, la « communauté web », nébuleuse de blogueurs, d’informaticiens et d’utilisateurs, s’est indignée. Ils ont, comme à leur habitude, dénoncé, avec beaucoup de créativité et de brio, cette loi liberticide et le danger qu’elle représente. Hélas ils n’ont pas été chercher plus loin les causes de cette loi, préférant dénoncer « un manque de démocratie ».

Chose rare, des professionnels du numérique ont milité contre cette loi. C’est en particulier le cas d’OVH, plus gros hébergeur et fleuron du numérique français. Cette entreprise, embauchant 1000 salariés sur son site de Roubaix a menacé de délocaliser tous ses datacenters à Québec en cas de vote de la loi. Simple mesure de survie : un hébergeur incapable de garantir la confidentialité des données de ses clients, perd une grande partie de son attractivité. D’autres hébergeurs sont déjà partis, comme altern.org et eu.org.

La « menace terroriste », même si bien réelle, ne peut justifier une telle loi. L’arsenal mis en oeuvre est complètement inutile pour la traque des terroristes, pédophiles et autres criminels organisés. Ces groupes sont formés à l’utilisation de moyens de cryptage. L’état n’a ni les moyens de repérer les trames suspectes, ni les moyens de les intercepter. La cryptographie permet d’anonymiser et de chiffrer les messages, de telle sorte que rien ne ressemble plus à un paquet chiffré terroriste qu’un autre paquet chiffré, parfaitement légitime. Il existe, sur Internet, des milliers de raisons de chiffrer non seulement légitimes, mais absolument indispensables : transactions bancaires, préservation de la vie privée ou secret industriel ou commercial ! Les organisations patronales s’inquiètent d’ailleurs de l’impact de cette loi sur les entreprises : personne ne viendra faire des affaires si l’état s’immisce dans les secrets industriels.
Deux options restent disponibles pour l’état : l’interdiction complète du chiffrage, sauf autorisation ou la course aux armements numériques avec les terroristes : toujours plus de surveillance, toujours plus intrusive et chère. La seconde voie est celle prise par les Etats-Unis, avec la NSA qui, malgré de formidables moyens (10 milliards de dollars) n’a pas su déjouer le 11 septembre ou les attentats de Boston ! Le dispositif français, lui, coûtera la bagatelle de 500 millions d’euros.

Il serait légitime de s’inquiéter d’une telle loi, même avec le gouvernement le plus vertueux du monde. Le ver est dans le fruit et cette loi peut très bien rester en sommeil des années, avant d’être ressortie par un régime devenu autoritaire. La Loi Renseignement met la police à disposition de l’administration, sans aucun contrôle judiciaire. Avec les discussions sur le vote obligatoire, la Loi Santé ou la dérive de plus en plus autoritaire d’un Manuel Valls, sans doute ne sommes-nous pas au bout de nos peines, le croisement de fichiers et la dictature algorithmique pouvant devenir la nouvelle « justice ».

Pourquoi la décroissance ?

Fri, 24 Apr 2015 00:00:00 +0000

Né dans les milieux écologistes et reprenant des thèses d’Ivan Illich, Jacques Ellul et Georgescu-Roegen, le mouvement décroissant se définit comme véritablement écologiste, par opposition aux Verts et aux partisans du développement durable. Ils accusent les uns d’être corrompus par le jeu partisan (sans pour autant dénoncer la logique partisane en elle-même, nous le verrons) et accusent les seconds de défendre un oxymore.

Il est normal que le terme de Décroissance sonne étrangement aux oreilles du profane. Selon Ariès, Latouche et d’autres figures du courant, ce slogan ne signifie pas l’anti-croissance, l’austérité forcée, ou bien la récession, mais la fin du culte de la Croissance, pendant économique de l’idéologie du Progrès. Bernard Maris disait à ce propos « La récession qui s’annonce n’est pas une forme de décroissance. Car la décroissance voulue par certains est une notion solidaire et équitable ». Nous n’avons donc pas affaire à de dangereux kaczinskystes, mais bien à des écologistes qui, s’étant débarrassés du Progrès, ont pu réellement penser l’écologie.

Là où les écologistes classiques cherchent partout des ersatz verts, afin de maintenir leur mode de vie en polluant moins, les décroissants appellent à une « décolonisation mentale ». Cette expression, récurrente à gauche, signifie pour les décroissants qu’il faut soigner l’esprit qui a attrapé le virus de la croissance (donc également du Progrès, bien que tous les décroissants ne fassent pas le lien). Ils veulent en arriver à un mode de vie sans croissance, néanmoins prospère et heureux, par l’abondance frugale : limiter le superflu et redécouvrir l’essentiel, simplicité et convivialité.

Mode de vie disais-je, car si certains décroissants ont un réel projet politique, d’autres en restent à l’incantation ou à l’ascèse personnelle. Les points que l’on retrouve le plus fréquemment chez ceux qui ont un projet sont la relocalisation, l’anti-productivisme, le convivialisme et le ralentissement du temps. D’autres points sont souvent trouvés, mais vivement débattus par les différentes chapelles de la décroissance. Citons par exemple les idées de revenu de base, d’universalisme ou de libertarisme, défendues ou vilipendées selon les courants et les penseurs. L’on peut déplorer que peu de penseurs de la décroissance actuels aient une véritable culture politique hors de la gauche. Beaucoup ignorent l’existence de penseurs écologistes hors-gauche, et restent dans la consanguinité idéologique. Ils n’ont absolument pas idée d’aller chercher des antilibéraux ailleurs, les croyant tous « de gauche », quoi que cela veuille dire.

Spirituellement, les décroissants se rangent en 3 groupes, le premier groupe, très représenté, n’a qu’un vernis spirituel assez superficiel. Ils dénoncent la perte de la vie intérieure et de la relation avec l’autre qu’engendre le capitalisme consumériste, avec de vagues mots comme « harmonie », « paix » ou « ré-enchantement ». Un certain nombre reste d’ailleurs assez marqué par un certain progressisme, même s’ils le dénoncent dans leur discours : ils refusent obstinément d’aller s’inspirer du passé pour trouver des solutions adaptables à l’avenir.

Un second groupe est le groupe des décroissants chrétiens qui, sans forcément la Foi, prônent les valeurs chrétiennes contre la société libérale. Ces « valeurs chrétiennes » sont assez difficiles à cerner, tant ce groupe est vaste. Ils se réclament d’Ivan Illich, prêtre catholique, de Jacques Ellul, théologien protestant et de Bernard Charbonneau, postchrétien agnostique. Ces décroissants chrétiens font souvent l’éloge de Saint François d’Assise, vu comme modèle d’homme à sa place dans la Création.

Le troisième groupe pourrait être qualifié de « païens » par opposition aux chrétiens. Ils sont représentés aujourd’hui par Pierre Rabhi (bien que religieusement chrétien) et Edward Goldsmith, principalement. Leurs références sont Gandhi, David Thoreau ainsi que les spiritualités grecques (références à Gaïa et au Cosmos), orientales (hindouisme, bouddhisme) et chrétiennes primitives (Tolstoï). Les concepts de Terre Mère et d’Alliance Sacrée entre la nature et l’homme sont au centre de leur philosophie. Alliance sacrée qui, contrairement à la pensée chrétienne, place l’homme au même niveau que le reste de la nature. C’est la différence fondamentale entre les deux. Les chrétiens sont anthropocentristes et les « païens » écocentristes.

Au-delà de ces différences spirituelles, les décroissants se rangent en deux groupes, selon le cheminement qui les a conduit vers la décroissance. On distingue des décroissants « économistes » et des décroissants « culturels » selon Christian Laurut. Les premiers sont partis du constat de la finitude du monde et de l’insatiabilité de la croissance (« Celui qui pense qu’une croissance infinie est possible dans un monde fini est soit un fou, soit un économiste » Kenneth Boulding), les seconds, soit d’un mal-être par rapport à la société de consommation, soit de convictions philosophiques ou religieuses.

Les décroissants « économistes » citent volontiers le Printemps Silencieux de Rachel Carson, où bien les conférences de Jean-Marc Jancovici (par ailleurs partisan du développement durable) comme leurs sources. Nicolas Georgescu-Roegen, père de la décroissance, semble avoir été influent dans la création du courant, mais est peu cité actuellement par les décroissants.
La décroissance est un courant assez hétéroclite, où l’on retrouve tout ce qui se trouve entre les primitivistes et les partisans du développement durable. Beaucoup de différences existent entre les décroissants, nous l’avons vu. Ces différences ne les empêchent pas de se rejoindre sur un objectif commun : abattre la société de consommation. Les raisons en sont diverses, le but reste le même. Si nous partageons cet objectif tout à fait louable, nous ne pouvons que rester sceptiques devant les modes d’action majoritairement utilisés par ce courant : que des nuances plus ou moins foncées de démocratisme. Certains, nous l’avons dit, refusent même la politique et font de la décroissance une ascèse personnelle. D’autres fondent des partis, pensant que s’ils arrivent au pouvoir, ils feront mieux qu’EELV. Enfin, d’autres font de l’entrisme, au sein du PG, d’EELV, voire du PS. Aucun n’évoque la possibilité d’une prise de pouvoir, même si beaucoup craignent l’avènement d’un « écofascisme », rendu inévitable par la dégradation de la planète.

D'où viennent les failles de sécurité informatique ?

Mon, 13 Apr 2015 00:00:00 +0000

Le piratage de TV5 Monde met sur le devant de la scène le potentiel de nuisance des failles de sécurité informatique. En informatique, une faille est un “trou” dans la sécurité, permettant à un attaquant de contourner une protection. Elles peuvent permettre, entre autres, la prise de contrôle d’une machine ou l’accès à des données confidentielles. Avec plus de 5000 failles recensées par an – et un nombre incalculable non répertoriées–, la sécurité informatique est loin d’être une science exacte. Et si la faille n’était pas une erreur regrettable, mais bien une réalité inévitable en informatique ?

Il faut avant tout rappeler qu’une faille est souvent accidentelle : les concepteurs comme les développeurs sont à l’origine d’inévitables erreurs humaines, générant des vulnérabilités parfois critiques : l’écrasante majorité des failles sont de simples et innocentes erreurs. C’est le cas de TV5, bien que la chaîne ait été irresponsable : l’ANSSI (Agence Nationale de la Sécurité des Systèmes d’information) les avait prévenus deux semaines auparavent de la découverte de vulnérabilités ! Notons qu’un administrateur nonchalant est la pire des plaies en matière de sécurité informatique.

Mais à coté de celles-ci, une minorité de failles sont introduites sciemment par les éditeurs, sans prévenir l’utilisateur. On les appelle “portes dérobées”, backdoors. Si quelques portes dérobées peuvent partir d’une intention louable (support technique transparent, mises à jour…), toute porte dérobée constitue une faute pour l’éditeur. Découvertes par un tiers malveillant, elles peuvent occasionner des dégâts importants. La très récente affaire Gemalto, entreprise française autoproclamée « leader mondial de la sécurité numérique » ( !), dont la NSA américaine a volé les clés de chiffrement des cartes SIM (gérant toutes les données des téléphones mobiles), est un cas d’école : Gemalto n’aurait pas dû conserver les clés.

Les deux origines majeures des portes dérobées dites “malveillantes” (ce terme est sujet à controverses) sont, d’une part, la pression des services de renseignement sur les éditeurs et, d’autre part, les accords officieux entre entreprises, portant sur l’accès aux données personnelles des clients.

Les révélations d’Edward Snowden ont jeté une lumière crue sur une partie des vastes programmes de la NSA américaine, gigantesques réseaux de collecteurs, puisant leurs informations dans le monde entier, partout où des logiciels ou du matériel américain sont utilisés. Snowden a dévoilé le dispositif des États-Unis, mais il est certain que toutes les puissances ont des méthodes similaires, à plus ou moins grande échelle. Il s’agit d’un impératif de sécurité nationale et de renseignement, tant intérieur qu’extérieur.

La légitimité du renseignement national est complexe, mais l’illégitimité des accords, souvent illégaux, entre sociétés privées ne fait pas débat. Dans le monde de la santé et de l’assurance, les données personnelles sont de l’or. De nombreux acteurs forment un vaste marché gris des données personnelles. Des portes dérobées, donnant accès directement aux données des clients, sous l’apparence de banales failles, sont un outil de choix pour alimenter ces marchés. Elles permettent de cacher sous le motif du “piratage”, un trafic de données personnelles.

La sécurité absolue n’existera jamais et la Haute Technologie (High Tech) amplifie les erreurs par sa complexité. En matière de sécurisation des échanges et des données, des solutions sont peut-être à chercher du côté de la « Basse Technologie » (Low Tech), voie explorée actuellement par les services russes, entre autres : ceux-ci utilisent depuis 2013 des machines à écrire pour la rédaction de tout document classifié. Sans doute une piste à explorer chez nous, afin d’éviter bien des fuites.

L’informatique n’est qu’un outil, pas un remède, car aucune technologie bonne par principe ou morale par essence.

Faille ou porte dérobée : une confusion bien commode

Thu, 12 Mar 2015 00:00:00 +0000

Dans le même temps que Snowden ou l’affaire Gemalto nous révélaient l’emprise de la NSA sur le monde numérique, de nouvelles failles de grande ampleur (Heartbleed, FREAK, POODLE) venaient remettre en cause des briques fondamentales de la cybersécurité.

Une faille est, par définition, un vice involontaire de conception. Or dans de nombreuses affaires récentes, il est avéré que la « faille » a été introduite volontairement dans le logiciel incriminé. Cette pratique, porte le nom de « porte dérobée », « backdoor » en anglais. Elle permet à un tiers de contourner les protections d’un logiciel, avec la complicité de l’éditeur.

Une faille peut égratigner une relation de confiance, surtout lorsqu’elle tarde à être corrigée. Elle reste néanmoins une erreur humaine tout à fait normale. Une porte dérobée est bien pire. Elle trahit la malhonnêteté manifeste de l’éditeur, ce qui annihile toute possibilité de confiance, sève de la sécurité. Rien ne prouve qu’une porte dérobée, supprimée avec mille excuses, n’aie pas simplement été cachée ailleurs. D’où l’intérêt pour une entreprise de déclarer comme « faille », toute porte dérobée pas trop flagrante. Une maniére de travestir la malhonnêteté en erreur humaine, ce qui est bien commode.

Les entreprises françaises sont bien peu au fait des dangers des portes dérobées. Elles accordent bien souvent une confiance absolue à des logiciels propriétaires (à « recette » secrète), appartenant à des éditeurs étrangers. Ce qui peut représenter de potentielles fuites de données sensibles vers des pays concurrents.

Critique de The Code

Tue, 24 Feb 2015 00:00:00 +0000

Série australienne actuellement en diffusion, The Code base son intrigue sur le thème très porteur du hacking et de la cybercriminalité. Un journaliste et son frère, hacker repenti, enquêtent sur la mort d’une adolescente, liée à un mystérieux camion au chargement top secret. La série tombe, hélas, dans un travers habituel du cinéma : le hacker est présenté comme une sorte de demi-dieu de l’informatique capable de hacker un site top secret en cinq minutes. Rien à voir avec la réalité du hacker, pouvant passer des nuits à la recherche de vulnérabilités le plus souvent inexploitables. La série pèche également en plongeant trop brutalement le spectateur dans l’intrigue, sans aucune introduction. Dommage car une fois les acteurs en tête, la série est plutôt plaisante à regarder et donne envie de connaître la suite. L’environnement australien dépayse, la réalisation est soignée et les acteurs sont bons.

Cybersécurité : promouvoir la création française

Thu, 19 Feb 2015 00:00:00 +0000

Le septième Forum international de la cybersécurité (FIC) vient de se tenir à Lille. Il est à la fois le relais et la sonde de la stratégie française en matière de sécurité des systèmes d’information. Cette manifestation étantétroitement liée à l’État, le discours d’ouverture a porté, sans surprise, sur la lutte contre le “cyberdjihadisme” et le renforcement de la surveillance. Ce discours anxiogène a, hélas, masqué le véritable intérêt du FIC : les dizaines de PME françaises et européennes venues nouer des liens entre elles et présenter leurs innovations. Si beaucoup n’ont fait qu’industrialiser des technologies méconnues venues du monde du logiciel libre, quelques acteurs ont su proposer aux entreprises des services de pointe à forte valeur ajoutée. Trois innovations ont retenu notre attention. La première est signée AriadNext, startup rennaise créatrice d’un service de validation en temps réel de documents officiels (passeports, RIB…). Leur produit, développé en partenariat avec l’administration, permet une sécurisation des souscriptions et une réduction du nombre de fraudes.

Capgemini tend un piège aux pirates

La deuxième est le système d’authentification de la société GenMSecure. Celle-ci a bâti une application ergonomique, remplaçant à la fois le traditionnel identifiant-mot de passe et les codes de validation par SMS pour toutes les transactions sensibles. Lorsqu’une opération requiert l’autorisation de l’utilisateur, celui-ci la confirme avec son téléphone, de manière sécurisée, par le biais d’un code unique. Citons enfin Capgemini, pour son positionnement sur le marché embryonnaire mais prometteur des honeypots. Un honeypot est un piège destiné aux cyberattaquants : s’il est invisible pour l’utilisateur normal, il attire dans un piège celui qui cherche à déjouer les mesures de sécurité. Quand un attaquant tente de s’introduire dans ce piège, il est automatiquement banni. Ce septième FIC s’est donc montré très positif. Plus d’une centaine d’exposants, des milliers de visiteurs et un secteur inventif.

Si le marché européen n’est rien par rapport au géant américain, le développement d’une expertise “locale” est capital dans une optique d’indépendance stratégique. Laisser les Américains ou toute autre puissance avoir pour clients des entreprises françaises revient à leur offrir l’accès à nos données… Le développement et la préservation d’une expertise française est en ce sens une priorité stratégique majeure.

Qu'est-ce qu’un développeur ?

Thu, 18 Dec 2014 00:00:00 +0000

Je suis un développeur. Cette phrase est une évidence désormais pour moi-même et mes collègues. Mais en quoi consiste la profession qui se cache derrière ce terme ? Cet article tente une définition du développeur, d’où qu’il vienne et où qu’il soit. Il exclut ceux qui sont passés du côté managérial de la force car ils n’ont plus le même métier.

Il est évident que le développeur est à classer dans le secteur tertiaire, selon la classification communément admise. Le développeur apporte une solution technique, majoritairement sous forme de code, c’est à dire de donnée (un traitement est une donnée), à partir de matière grise et d’outils informatiques. Son métier n’a aucun lien direct avec le monde des objets physiques. Il ne peut avoir un lien avec celui-ci qu’en contrôlant des objets électromécaniques ne faisant pas partie de son domaine de compétence propre. Il ne travaille que dans le monde du logiciel.

Le travail

Le travail du développeur est en 3 parties, souvent confiées à d’autres acteurs à mesure que les équipes grandissent :

Il doit tout d’abord analyser et comprendre un problème. Parfois le problème doit être extrait des pensées confuses d’un non-technicien ce qui n’arrange rien. Heureusement le chef de projet a été inventé pour le dialogue client ! Si l’équipe ne travaille pas avec les méthodes agiles, un cahier des charges est produit puis validé par le client.
Le développeur doit ensuite trouver une solution technique à un besoin et la traduire en code. Dans les équipes de taille réduite c’est le développeur qui découpe son travail lui-même. Plus la taille augmente, plus il est cantonné à une partie infime du tout.
Cette partie est le cœur nucléaire du développement (ou l’usine à gaz, c’est selon), l’analyse et la programmation sont la définition même du métier. Ici le développeur utilise son intelligence pour reproduire sous forme de traitements informatiques le comportement attendu dans les spécifications de la tâche qui lui est attribuée. Il utilise pour cela, des notions théoriques, son expérience mais aussi sa vision des choses et sa manière de penser.
La troisième partie est la livraison : la solution technique doit être rendue disponible au client. Cette partie comprend l’installation, la documentation et la démonstration. Dans les équipes de taille supérieure, des personnes sont attribuées spécifiquement à cette tâche. Le débogage éventuel, qui suit cette phase, entre dans la même catégorie que la production technique initiale. Le bug est la conséquence d’une malfaçon (humainement normale ou non).

La formation initiale

La formation d’un développeur est assez hybride, entre une formation d’ingénierie et une formation artisanale. Très souvent, surtout en école privée, le développeur est également formé au management, en vue d’une évolution future vers des postes de ce type. Dès son premier jour de formation, souvent même avant, le futur développeur pratique la programmation. La conception n’est pas encore une préoccupation pour lui mais rapidement, par l’échec pratique et la formation théorique, l’apprenant va commencer à concevoir des systèmes de plus en plus complexes, réutilisables, interopérables et maintenables.

La virtualité du code détermine le mode de formation. C’est parce que coder n’a pas d’autre conséquence sur le monde réel que de consommer de l’énergie, que le développeur peut échouer et recommencer tant qu’il le souhaite, avant de rentrer dans le monde professionnel où son temps devient de l’argent.

Deux grands courants s’affrontent concernant l’instruction des développeurs : l’approche projet et l’approche magistrale.

Pour les tenants de l’approche projet, l’apprenant doit au cours de son cursus, mettre en application ses compétences dans des projets encadrés. Il sera noté à la fois sur ces projets et sur des compétences théoriques dispensées pendant des cours. Cette approche a l’avantage d’harmoniser le niveau technique d’une promotion, mais au prix de la créativité des plus entreprenants.

L’approche magistrale, elle, ne note que sur les compétences théoriques. Elle laisse à la curiosité des apprenants l’apprentissage pratique. Son inconvénient principal est d’avoir en sortie des niveaux assez disparates de compétences pratiques, variant selon la curiosité de chacun. Pour cela, elle se retrouve plus dans les facultés que dans le privé, qui souhaite maintenir une « cote » homogène à son diplôme.

La profession n’exclut pas les autodidactes, bien qu’ils puissent avoir plus de difficultés à entrer et à progresser dans l’univers de la grande entreprise.

La formation continue

La formation d’un développeur n’est jamais terminée. A moins qu’il ne travaille dans le seul entretien d’un existant sénescent (COBOL, vieux mainframes …), le développeur a le devoir de se tenir informé des nouvelles technologies du numérique en général. Le développeur étant souvent technophile (technocritique à minima) cette partie ne lui pose en général aucun problème.

La seconde obligation du développeur est de ne jamais arrêter son entraînement. A l’image des maîtres des anciens Métiers, il doit toujours être en recherche de l’amélioration. Le développeur est un véritable artisan : le seul moyen qu’il possède d’augmenter sa productivité est de s’améliorer lui-même, nulle machine ne peut remplacer l’essence de son métier qui est de concevoir (lorsque ce jour sera venu, il faudra sérieusement s’inquiéter).

Si le développeur doit tendre à la perfection individuelle, la même chose vaut pour l’équipe. La méthode utilisée, en revanche, diffère fondamentalement selon que l’on se trouve dans une petite équipe ou dans une équipe plus grande. Dans une petite équipe, l’amélioration se fera principalement par la discussion et la découverte de synergies entre les membres. Dans une équipe plus grande, il est impensable qu’un développeur connaisse bien tous ses collègues ! L’amélioration des performances devient une question organisationnelle dépendant de la hiérarchie. Elle passe souvent par une division du travail et une standardisation des environnements et méthodes. Le développeur a moins son mot à dire.

Les outils

Pour son travail le développeur utilise un ordinateur. Cela paraît idiot à dire mais mérite d’être dit car cela inclut deux choses : l’ordinateur comme interface physique (clavier, souris, écran(s)) et l’ordinateur comme plateforme logicielle. L’efficacité des deux influe sur la productivité du développeur.

Le développeur accomplit sa mission en utilisant un ou plusieurs langages de programmation. Ils sont traduits en langage machine par un compilateur ou un interpréteur. Très souvent, le développeur entoure cet outil fondamental d’une suite d’autres outils, qui constituent son environnement de développement. Dans les faits, la multitude des options de configuration permet de ne jamais trouver deux développeurs avec exactement le même environnement. Si, pour garantir la cohérence d’une équipe, certains outils doivent être partagés, la majeure partie est entièrement personnalisable. Même dans les équipes massives le développeur ne sera jamais complètement standardisé.

La productivité de l’environnement est un facteur majeur de productivité du développeur. Avec cet environnement il va produire du code de deux types : applications et modules. Les applications sont destinées à un usage précis et sont un agrégat de modules, cimentés par du code. Les modules sont, eux, destinés à être réutilisés dans plusieurs applications, ils peuvent être considérés comme des outils et comme des sous-produits.

Les modules sont un facteur crucial de la productivité d’une équipe de développeurs. Ils permettent de ne pas réinventer la roue à chaque fois, en posant des interfaces simples sur des procédures plus complexes. Ils ont également l’intérêt de factoriser le code : un module crée une fois peut être appelé dans plusieurs parties d’un code. Enfin, ils le remplacement aisé de parties d’un programme, en minimisant les changements à opérer sur le tout.

Rapport au travail et à l’emploi

Le développeur est un employé de bureau, qu’il travaille dans des locaux d’entreprise, chez lui ou bien en nomade. Son rapport à l’emploi est exactement le même que pour un employé de bureau classique et dépend fortement de la structure dans laquelle il choisit de travailler. Le poste et la mentalité d’un développeur change radicalement selon qu’il soit dans une PME ou une grosse structure. Son appréciation de son travail dépend principalement de la taille de l’équipe à laquelle il est intégré.

Un point cependant change fondamentalement par rapport à l’employé de bureau, point qu’il peut partager avec l’ingénieur ou le chercheur : Le rapport du développeur à son travail est essentiellement d’ordre artisanal. Le développeur s’identifie plus volontiers par ce qu’il fait, que par où il le fait. Chez le col blanc « classique » c’est l’entreprise et la position hiérarchique qui identifient la personne. Ce penchant artisanal se retrouve également dans les projets personnels, plus ou moins nombreux et achevés, que le développeur réalise en extra-professionnel, caractéristique que l’on retrouve chez certains artisans.

Un développeur travaillant en grande entreprise a tendance à faire partie d’équipes plus grandes, tenant souvent plus de la chaîne de montage que de l’équipe humaine. Cela n’est pas toujours vrai mais ça change le rapport qu’il peut avoir à son travail : en grande équipe il s’identifie plus par sa position, tel l’employé de bureau, que par ses réalisations. Le développeur qui ne travaille que sur une petite partie d’un tout sans en avoir forcément une vision d’ensemble, aura bien plus de mal à s’y reconnaître.

Le pouvoir

Le développeur est un technicien : c’est-à-dire qu’il est formé à des techniques auquel le commun des mortels ne comprend rien. Il a donc un ascendant sur l’utilisateur final non-technicien. Dans beaucoup de situations, le conseil est une obligation légale. Dans le reste des cas, c’est au développeur en son âme et conscience de décider quel degré de transparence, d’honnêteté et de pédagogie il appliquera.

Le technicien-développeur produit du code. Ce code n’est pas neutre : il impose à l’utilisateur la vision du commanditaire, déformée par le développeur. Lorsque les traitements dans l’entreprise sont entièrement manuels, l’empirisme et le ressenti produisent des méthodes de travail relativement souples, sauf ordres stricts de la direction. Lorsque l’on remplace l’humain par l’ordinateur il se produit une réduction de la créativité. L’ordinateur est aussi créatif que drôle. La créativité d’une équipe humaine est bridée par la rigidité de la machine. Si le développeur à le pouvoir d’assouplir et de rendre ergonomiques ses solutions, jamais il ne pourra s’empêcher d’imposer de la rigidité.

Le code n’est pas non plus sans conséquences économiques. En particulier le code de mauvaise qualité. La gravité économique de la sous-qualité dépend de deux facteurs : la criticité de l’application et l’ampleur des défauts. Le principe de Peter est fondamental lorsqu’il s’agit de manager des développeurs. Un mauvais développeur placé à un endroit stratégique peut couler, ou gravement handicaper, une entreprise. Mieux vaut pas d’outil informatique du tout, qu’un outil qui représente une perte de productivité à un poste donné. D’autant que le développement à un coût non-négligeable.

Conclusion

Le développeur est une sorte d’hybride entre deux tendances : l’artisan-codeur et le salarié du tertiaire. Le poids de chaque tendance varie selon le contexte de travail. Armé d’un ordinateur et de son cerveau, le développeur va, seul ou en équipe, bâtir les briques de la société de l’information, colonne vertébrale de nos sociétés post-industrielles. Tout, aujourd’hui, est informatisé. Si la technique informatique n’est pas neutre en elle-même, les traitements informatiques le sont encore moins car elles sont des œuvres humaines. L’humain derrière chaque application se trouve être un développeur, avec ses compétences, son éthique, sa vision du monde, sa manière de travailler et ses idées. Si ce qu’il réalise est soumis à des contraintes (contractuelles, physiques, informatiques), il joue néanmoins un rôle majeur dans la manière dont se dessine la société de demain, rôle proportionnel à la place qu’occupe l’informatique dans celle-ci.

Test d'Assassin’s Creed Unity

Wed, 19 Nov 2014 00:00:00 +0000

Moins manichéen que ses prédécesseurs, techniquement réussi mais historiquement passable, le dernier jeu de la série Assassin’s Creed se révèle bien plus intéressant qu’attendu.

Les augures étaient bonnes : ce cher Mélenchon ressorti de son placard pour critiquer un jeu; il ne pouvait pas être si mauvais que ça.Je ne m’attarderais pas sur les bugs, ne les ayant pas expérimentés sur ma machine, ni sur l’optimisation, très variable selon le hardware de chacun.

Une oeuvre vidéoludique

La première chose qui frappe en se plongeant dans ce jeu est qu’il est beau. Paris est modélisé avec une myriade de détails, à l’échelle 1:1 s’il-vous plaît pour une zone délimitée par les Invalides, le Panthéon, la Bastille et l’ancienne Madeleine. Une ville vivante, même si les dialogues sont parfois un peu illusoires (les gens pensaient à manger, pas à crier « mort au tyran » à chaque coin de rue). Musicalement c’est cohérent et beau, la musique colle aux situations, l’ambiance électrique de la Révolution est parfaitement rendue dans la bande son.

La ville fourmille de quêtes, souterrains, personnages à rencontrer, bâtiments à explorer (premier jeu de cette série avec autant d’intérieurs accessibles).

Les modélisateurs comme les artistes ont fait un excellent travail pour ce jeu.

Un gameplay bien amélioré et plaisant

Assassin’s Creed souffrait de pas mal de défauts dans les opus précédents : la linéarité et la répétitivité du jeu, la course libre peu contrôlable, le manque d’infiltration pour un jeu d’assassins. Visiblement Ubisoft a entendu les plaintes des joueurs et en a pris compte. Le jeu fourmille de quêtes annexes variées et ancrées dans les anecdotes historiques parisiennes. La course libre a été grandement améliorée, si il reste quelques imperfections, le côté simiesque des déplacements a disparu. Le héros ne monte plus n’importe où de manière illogique.

Enfin l’infiltration occupe la place qu’elle aurait toujours du occuper dans un jeu de ce genre. Même si un mode difficile manque avec des ennemis plus réceptifs et réactifs, il n’est désormais plus possible de foncer dans le tas face a des ennemis de même niveau, sous peine de mort.

Le mode coopératif est très intéressant pour peu de jouer avec des amis. La sélection aléatoire tombe souvent sur des joueurs mauvais ou indisciplinés. Le coté RPG Coopératif est intéressant avec de l’équipement permettant de choisir un style de jeu.

Historiquement incorrect

Sur le plan historique, le jeu présente un bilan mitigé, voire désastreux par moments.

Une mission fait par exemple fait la déplorable erreur de dire que les hébertistes furent des « fanatiques royalistes ». Le peuple tient des discours incohérents pour l’époque, se préoccupant plus de grandes idées que du manque de pain. Le jeu laisse penser que l’Ancien Régime était dépourvu de justice (le héros est embastillé pour un meurtre qu’il n’a pas commis, sans aucune forme de procès). La narration n’hésite pas à invoquer le mot « peuple » à toutes les sauces, oubliant les inégalités criantes entre la bourgeoisie (absente du jeu) et le bas-peuple.

Le jeu présente des points positifs néanmoins, la noblesse et le clergé ne sont pas caricaturés outre mesure. Beaucoup de figures de la révolution ont l’image qu’ils méritent, Mirabeau, Robespierre, Bonaparte ou encore le Marquis de Sade, rendu à merveille ! Le roi Louis XVI est représenté assez justement. Il est mal préparé au trône, dans une époque impitoyable et mouvementée et cela ressort bien.

La barbarie de la Révolution est omniprésente, que ce soit avec les radicaux violents ou par le biais de scènes comme les massacres de Septembre.

Idéologiquement mitigé

Il ne faut pas se leurrer, ce jeu reste un Assassin’s Creed, avec le message anarchiste que la série propage depuis le début. Le jeu se conclut par un message d’un athéisme déplorable, les missions moralement douteuses sont légion (voler des calices consacrés pour s’infiltrer dans le culte de Baphomet …). Le jeu est néanmoins assez délicat pour ne pas tirer sur l’Église, reconnaissant même qu’elle partageait la misère de ses fidèles. La fin du jeu prend même la forme d’un dialogue entre le Grand Maître des Templier parlant de « progrès inéluctable » et les assassins, prônant le libre arbitre face à un destin imposé d’avance. Serait-ce une représentation du la querelle du libre-arbitre et de la grâce ? La plus grande surprise de ce jeu est qu’il n’est pas frontalement anti-monarchique, même si il fait passer la monarchie comme dépassée par la « Liberté » selon les moments. Louis XVI est bien décrit comme victime d’un procès truqué, ses derniers mots où il espère que « son sang servira à cimenter le bonheur des français » ne sont pas oubliés. Les déclarations des Templiers sont même complètement inespérées : « Lorsque la mitre et la couronne tombent c’est l’or qui détermine qui a le pouvoir ». Les Templiers en eux-mêmes montrent les rouages qui ont amené à la révolution. Durant tout le jeu ils manipulent le peuple, jouent sur les cours du grain, paient des orateurs, incitent au massacre, assassinent les modérés … La Terreur est leur œuvre.

Conclusion

Techniquement c’est une réussite. On peut regretter le manque d’experts historiques sérieux (ils ont travaillé avec seulement 2 référents, dont un niant le génocide vendéen). Idéologiquement on peut trouver des points très positifs, même si Assassin’s Creed nous réchauffe la même soupe libertaire et anarchiste. Impossible de se positionner dans ce conflit autrement que pour la Liberté abstraite. Ce jeu est moins manichéen que ses prédécesseurs mais reste encore assez moyen sur ce plan.

Néanmoins, d’un point de vue personnel, je recommande ce jeu, très plaisant à jouer et moins mauvais que ses prédécesseurs sur bien des points.

Si je devais le noter, ce jeu aurait un 16/20.

Protéger ses données, tout numérique ou retour à l'analogique ?

Thu, 06 Feb 2014 00:00:00 +0000

Vous souhaitez envoyer une information sécurisée ?
Envoyez-là par La Poste, en double enveloppe, la seconde à l’envers dans la première.
L’analogique coûte bien trop cher pour pouvoir le surveiller massivement.
Une enveloppe simple protège très mal, il est peu difficile de glisser une caméra dans l’enveloppe en cas de doute (destinataire ou expéditeur fichés par exemple).
Pour un maximum de sécurité, n’hésitez pas à accompagner votre courrier d’un vieux brouillon, rendant même la plus puissante lampe inutile pour un déchiffrage par transparence.

Soyez old school, c’est tellement minoritaire que ça n’est que peu surveillé.
Pour des fichiers, le mieux reste si vous ne savez pas comment crypter solidement, d’envoyer une bête carte SD par la poste (toujours en double enveloppe).

Ainsi le numérique, encapsulé dans de l’analogique, reste loin des grandes oreilles.

La voix est pas mal non plus. Pour peu que l’on se débarrasse de son téléphone, capable entre autres :
-D’écouter en champ proche
-De géolocaliser la personne (par GPS ou antenne)
-Certains modèles sont suspectés de photographier discrètement
-Les dernières bouses d’Apple enregistrent en plus vos empreintes, me dites pas que c’est juste pour éviter le vol du téléphone

Attention aussi avec les PC, aucune preuve formelle, mais je ne vois pas à quel titre ils ne feraient pas ce qu’ils font dans les téléphones.
En particulier les webcams, n’ayez pas confiance en la LED (mettez un cache). Les micros intégrés à tous les PC portables sont également à redouter. Là pas tellement de solution sinon une ouverture et débranchement (ainsi vous choisissez quand utiliser le micro en en branchant un externe)

Je voudrais terminer avec les OS. Fuyez Windows et Mac OS pour vos activités sensibles. Ils ont ouvert leur code aux gouvernements, pas aux utilisateurs. Cela veut tout dire.
Linux est de plus en plus accessible au grand public et sauf pour les joueurs, je ne vois pas de problèmes bloquants.

Plus que jamais il faut agir cachés. Le gouvernement dispose de moyens d’écoute extrêmement performants pour traquer et tenir dans son œil les éléments séditieux.
Mais nous ne sommes pas désarmés pour autant.

Soit on en a les compétences ou l’on souhaite les acquérir et on peut utiliser la technologie contre eux. Mais ces compétences requièrent un apprentissage et la moindre erreur peut créer une faille critique.

Soit on opte pour du classique, ce qui, bien fait est tout aussi efficace.
Après tout, Unabomber a réussi grâce à son rejet total de toute technologie et à son intelligence à rester l’homme le plus recherché des U.S.A pendant 18 ans. (Je ne dis pas de suivre son exemple en termes de modes d’action hein !)