Note de lecture : Application Security Program Handbook, par Derek Fisher

Note : 7 ; Pour nous guider dans la mise en place de la cybersécurité.

Il faut commencer par ouvrir ce livre pour en comprendre le titre. Il s’agit bien de sécuriser les applications, mais plutôt sous l’angle de la gouvernance et de la mise en place de cette sécurisation. Dit ainsi, cela n’a rien d’attrayant et le texte aurait pu être terriblement rébarbatif. Il n’en est rien, et nous allons voir pourquoi.

L’ouvrage est parfaitement rythmé : il compte 260 structuré en 3 parties, chacune d’entre elle comptant 3 chapitres. La première partie sert à camper le décor, elle sert à nous permettre d’appréhender ce qu’est la sécurisation d’une application. Le chapitre 1 réponds au « pourquoi » de la sécurisation, mais en réalité va bien plus loin. Tout d’abord en introduisant le fameux « security program » qui est la raison d’être du livre, mais surtout en introduisant le securisation pipeline qui est l’apport majeur du texte et défend une approche « shift left » qui parlera bien aux agilistes.

Le second chapitre « understanding the problem” adresse deux sujets majeurs, le premier sera mon préféré, j’ai parlé de la triade CIA : confidentialité, intégrité, disponibilité (availability). L’auteur rentre en profondeur sur chacun de ces thèmes, détaillant la manière de les adresser. Un excellent boulot. Le second thème traite des risques : si j’ai aimé la classification et la présentation des types d’attaquants, la gestion des risques elle-même, s’appuyant sur le NIST, est plus austère. Le dernier chapitre de cette première partie est consacré aux composants de la sécurisation des applications. Tout d’abord on y trouve une excellente introduction à la modélisation des menaces, puis un panorama des outils d’analyse et enfin une évocation des différents types de test. Bref, ce chapitre est une petite mine d’or !

Continuer à lire « Note de lecture : Application Security Program Handbook, par Derek Fisher »

Note de lecture : Effective Software Testing, par Mauricio Aniche

Note : 7 ; Une stratégie de tests gravitant hélas uniquement autour des tests unitaires, mais faisant un excellent travail pour en systématiser l’approche.

En matière d’ingénierie logicielle moderne, la littérature sur les tests tend à se concentrer sur les tests unitaires et les tests d’acceptation. Les ouvrages qui englobent les pratiques de manières plus larges ciblent surtout l’aspect méthodologique. C’est donc avec intérêt que j’aborde ce texte qui se focalisent sur les différents types de tests que l’on peut mettre en œuvre au niveau des équipes de réalisation. Et nous allons le voir, cela ne se limite pas aux deux types de tests que nous venons d’évoquer.

Avec 274 pages hors annexes, cela reste un ouvrage de taille raisonnable. Il est structuré en 10 chapitres. Le premier chapitre annonce la couleur : les développeurs qui testent versus ceux qui ne testent pas. L’idée est ici d’avoir un tour d’horizon des types de tests qui vont être abordés et de l’aspect méthode et automatisation qui, même si on ne parle pas d’agilité, restent dans la même idée. Mon désaccord principal, sur ce chapitre et sur le livre, est d’utiliser la pyramide de tests comme boussole, une idée absolument dysfonctionnelle. Bien sûr, l’auteur met l’accent sur les petits tests qui s’exécutent rapidement (donc les tests unitaires), je ne saurais lui reprocher. Mais les autres tests sont pour lui : les tests d’intégration (quels tests d’intégration ?), les tests système et les tests manuels et c’est tout ! Pas de tests fonctionnels ou au moins de tests d’acceptation. C’est une vue erronée du paysage des tests, mais cela ne veut pas dire que l’ouvrage n’a pas d’intérêt.

En fait le chapitre 2 aborde le « specification-based testing ». Mais pas au sens des tests d’acceptation. Il s’agit ici de mettre en place des tests unitaires pour tester les règles de gestion à bas niveau. L’auteur y propose une démarche très systématique en 7 étapes allant des premiers tests passants aux tests aux limites puis « créatifs » sans oublier l’automatisation ! C’est de fait une approche très disciplinée des tests unitaires, peut-être trop, mais cela reste une très bonne source d’inspiration. Le texte ne s’arrête pas là puisqu’il aborde le traitement des bugs. Le propos est largement adossé à de très nombreux exemples en Java. Mais à mon avis l’illustration a travers de règles de validation sur une chaine de caractère n’est pas assez significatif d’un véritable projet.

Continuer à lire « Note de lecture : Effective Software Testing, par Mauricio Aniche »

Note de lecture : Grokking Continuous Delivery, par Christie Wilsonci

Note : 7 ; Pour s’initier sérieusement au continuous delivery

Cette série « grokking », c’est un peu le « pour les nuls » de Manning. Et tout comme cette série, ce n’est pas nul du tout. L’ouvrage rentre en profondeur dans le sujet, avec simplicité et pragmatisme, mais certainement pas avec simplisme. Comme nous le verrons, il s’avère même étonnant, en plus d’être abondamment illustré. Cela nous explique les 360 pages de cet ouvrage (hors annexes). Aussi, si la lecture est aisée, elle demande quand même un certain temps !

Le livre, justement, parlons-en. Il est structuré en 4 parties pour un total de 13 chapitres. La première d’entre-elles est une introduction sur 2 chapitres et un peu plus de 30 pages. Comme on peut s’y attendre, le premier chapitre est purement introductif, définissant le concept et ses concepts adjacents et lui donnant une perspective historique. C’est en fait une bonne idée, tellement il peut y avoir de subtilité entre les concepts et le texte ne fait pas l’impasse dessus. Il est précis et concret. C’est un bon chapitre. Le second chapitre s’inscrit en parfaite continuité pour décrire un pipeline de base en s’appuyant sur un cas d’étude, en l’occurrence des photos de chat. L’auteur nous prends par la main pour construire progressivement ce qui est un pipeline CI, finalement loin d’être basique. Tout ce fait progressivement en expliquant les concepts tels que guichet et transformation, progressivement. Seules les notifications par Webhook sont un peu spécifiques dans le paysage.

La partie 2 couvre les mises en œuvre nécessaires pour conserver un logiciel dans un état délivrable tout le temps. Elle pèse 5 chapitres sur 140 pages. Le chapitre 3 adresse la gestion de version et la startup de Sacha et Sarah va nous aider à y voir plus clair. Le texte fait le choix d’utiliser Github comme exemple. Il en fallait bien un, et il parait raisonnable. Cela permet de se familiariser avec les concepts de push et pull request. Le texte ne s’arrête pas là, il fait la transition avec le pipeline, et pourquoi pas dans le cloud ? Il adresse aussi la gestion de configuration en gestion de version en imaginant la connexion à une base de données également dans le cloud. Les auteurs vont plus loin que la gestion de version sensu-stricto. C’est un choix de l’auteure que nous retrouverons régulièrement.

Continuer à lire « Note de lecture : Grokking Continuous Delivery, par Christie Wilsonci »

Note de lecture : Exploring Requirements: Quality before design, par Donald C. Gause & Gerald M. Weinberg

Note : 7 ; Pour capturer et écrire plus efficacement des exigences.

Le moins que l’on puisse dire est que ce livre ne date pas d’hier ! Il attire toutefois l’attention par au moins deux aspects : le premier est la cosignature de Gerald Weinberg. Le second se situe dans le titre car il y est question non pas de gérer, de collecter ou de capturer des exigences, mais de les explorer. C’est sans doute pour cela qu’il va être moins questions de processus que de pratiques centrées sur l’humain et l’aspect psychologique de cette exploration. Par certains côtés, on y côtoie l’agilité avant l’heure !

L’ouvrage en lui-même n’est pas anodin : il totalise près de 300 pages structurés en 25 chapitres, eux-mêmes regroupés en 5 parties. Toutefois l’ensemble se lit bien. La première partie compte un peu moins de 50 pages pour 4 chapitres et son thème attire tout de suite l’attention, car il y est question de négocier une compréhension commune ! Le premier chapitre prend le contrepied des méthodologies, mais en fait c’est des notations qu’il s’agit. Et les auteurs, à l’aide d’exemples très simples mettent en évidence à la fois la difficulté sous-estimée de compréhension des notations et introduisent la notion d’ambiguïté des exigences, qui sera particulièrement le sujet du second chapitre. Ce second chapitre est plutôt court et va se limiter à définir cette notion d’ambiguïté dans le domaine du recueil des besoins, et ses conséquences. Mais ce thème reviendra au long de l’ouvrage.

D’ambiguïtés, il est toujours question au chapitre 3, qui va adresser les sources d’ambiguïté : observation, interprétations dans lesquelles le facteur humain vient s’insérer. Les recherches de Daniel Kahneman n’étaient pas encore popularisées mais elles auraient pu être citées ici. Les auteurs mettent néanmoins en relief ces biais au travers d’exercices pratiqués en séminaire. Pour refermer cette première partie, les auteurs s’attaquent à la pratique des questions directes au travers d’arbres de décision. Sans citer les biais cognitifs, ils mettent en question le postulat sous-jacent : la nécessité de s’adresser à des « êtres humains parfaits ». S’ils ne sont pas opposés à leur emploi, le verdict est que cette pratique ne suffit pas.

Continuer à lire « Note de lecture : Exploring Requirements: Quality before design, par Donald C. Gause & Gerald M. Weinberg »

Note de lecture : Making Sense of Cybersecurity, par Thomas Kranz

Note : 8 ; La cybersécurité pour les nuls, mais sans être nulle. Une lecture riche et passionnante à lire.

La cybersécurité, ce n’est pas nécessairement très facile de comprendre ce que c’est. Même une fois cette étape passée, il s’agit d’appréhender ce que cela recouvre et comment cela se décline en termes de mise en œuvre. Le présent ouvrage a pour objectif de s’attaquer à cette tâche pour le moins ardue, et à ma grande surprise il le fait bien, avec un propos accessible sans être débilitant et même avec une pointe d’humour. Bien sûr, comme le texte est émaillé d’anecdotes issues de l’expérience de l’auteur tout cela devient bien plus vivant.

Le livre lui-même est de taille moyenne, avec ses 256 pages. Il est structuré en 12 chapitres, dont 2 d’introduction suivi de 2 parties. Le premier chapitre « cybersécurity and hackers » commence en douceur pour nous faire prendre conscience des enjeux de la cybersécurité. En commençant par l’histoire du château de Warwick, il nous entraine vers les défis de la défense du système d’information. Le style de l’auteur coule tout seul et préfigure le reste de l’ouvrage. Le second chapitre nous assène dans le titre que la cybersécurité est le problème de tout le monde. L’auteur nous y présente son mantra qu’il répètera au fil des chapitres : la mise en œuvre des mesures doit être adaptée, proportionnelle à la menace et soutenable dans le temps. Elle se met en œuvre au travers de 3 questions simples : Quels assets possédez-vous ? Qui peut vouloir vous attaquer ? Quelles défenses mettez-vous en œuvre ? Au travers de ce discours épuré, l’auteur nous montre une autre de ces qualités, celle de présenter un discours clair, simple et pertinent.

La première partie, même si elle n’a pas de titre, est consacrée aux attaques. Elle comporte 5 chapitres sur 125 pages. Elle s’ouvra sur un chapitre 3 sobrement intitulé « comprendre les hackers ». L’auteur a choisi la classification white hat, grey hat et black hat. Son but est de nous faire comprendre l’état d’esprit des hackers. Il le fait en nous dressant de courtes biographies et quelques exemples. Avec la concision qui le caractérise, il résume la démarche du hacker : comment est-ce que cela fonctionne ? Comment je peux le casser ? Qu’est-ce que je peux lui faire faire d’autre ? Qu’est-ce que cela signifie comme possibilités pour moi ? Le chapitre 4 est consacré aux attaques externes. Il s’ouvre sur la boucle OODA (observe, orient, decide, act) et sa déclinaison en 4 questions que nous avons vu précédemment. Mais tout cela va mieux en le faisant. Ainsi l’auteur décline la manière d’opérer d’abord sur une infrastructure domestique, puis sur une architecture d’entreprise. Le chapitre ne serait pas complet sans un panorama des différentes attaques, que ce soient des classiques de l’OWASP, du mobile, du Wifi, etc. A chaque fois cela est expliqué avec clarté et une dose de légèreté qui nous ferait presque oublier que nous apprenons des choses au fil des pages.

Continuer à lire « Note de lecture : Making Sense of Cybersecurity, par Thomas Kranz »

Note de lecture : Requirements by Collaboration, par Ellen Gottesdiener

Note : 4 ; Malheureusement bien pauvre sur la substance même de cette collaboration !

J’ai été attiré par ce titre, aussi bien par le thème aussi original qu’important dans les pratiques d’identification du besoin, que par des recommandations tierces. La littérature adressant la manière de collecter, structurer et formaliser les exigences est très importante. Nombre de ces ouvrages sont d’ailleurs excellents ! Mais les textes traitant des interactions entre personnes pour les faire émerger est beaucoup plus réduite. Le présent ouvrage est peut-être le seul entièrement dédié à ce sujet ! Le texte n’est pas récent, il date du début des années 2000 alors que l’agilité en était à ses débuts. Aussi n’y trouverons-nous aucune référence à ce mouvement, même si de nombreuses idées sont convergentes.

Le livre lui-même comprends près de 280 pages. Il est structuré en 3 parties pour un total de 12 chapitres. La première partie nous promet un tour d’horizon des ateliers de définition des exigences, sur 3 chapitres pour environ 65 pages. Elle s’ouvre sur un très classique « getting started », en guise de premier chapitre. Il a pour but de cadrer la suite du sujet, tout d’abord en définissant les différents types et niveaux d’exigences. Ensuite en clarifiant la notion d’ateliers, ceux abordés ici s’inspirent du Join Application Design (JAD) qui nous conduisent à considérer différents types d’ateliers en fonction de leurs finalités. Le chapitre fait bien le travail, on y voit bien plus clair en l’ayant terminé.

Au chapitre 2, nous allons rentrer plus en profondeur sur ce que nous cherchons obtenir des ateliers, donc les artéfacts. Pour ceux qui ne sont pas familiers de la littérature sur la gestion des exigences, ce sera sans doute une découverte de voir le nombre et la variété de ces artéfacts. Bien que l’on ne rentre pas encore dans le cœur du sujet, le propos est intéressant et bien construit. Cette première partie se clôt sur l’aspect préparatoire des ateliers : l’espace, les invitations, l’état d’esprit avec lequel il faut venir. C’est un peu verbeux et enfonce parfois les portes, mais cela reste bien fait.

Continuer à lire « Note de lecture : Requirements by Collaboration, par Ellen Gottesdiener »

Note de lecture : Pragmatic Version Control, using Git, par Travis Swicegood

Note 4 ; Informatif, mais pas passionnant.

Git, depuis son apparition est rapidement devenu le standard de fait de la gestion de version. Après avoir commis la gestion de version pragmatique avec CVS puis Subversion au début des années 2000, il devenait évident de proposer l’ouvrage équivalent pour Git. Équivalent il l’est car, comme nous allons le voir, il s’agit essentiellement d’une transposition du même texte au monde Git.

Le livre est plutôt court, avec 150 pages, mais découpé en petits chapitres, puisqu’il en compte 11, regroupés en 3 parties. La première partie est consacrée à l’installation et à la mise en œuvre initiale de Git. Le premier chapitre, c’est le tour du propriétaire. On y retrouve les concepts de base de la gestion de version, correctement actualisés par rapport à Git, mais sans exposer ses particularités outre mesure. Un bon chapitre pour les débutants sur la gestion de version, mais qui apporte peu pour les autres. Le second chapitre évoque l’installation et la configuration de base de Git. C’est vraiment du pas à pas pour différents systèmes d’exploitation, pas la peine de s’attarder. Avec le 3ème chapitre qui referme cette première partie, cela devient plus sérieux : il s’agit de créer un projet. En fait, on y fait même plus que cela : on y ajoute des fichiers et opérons quelques commandes de base. Le livre commence vraiment avec ce chapitre.

La seconde partie évoque l’utilisation de Git au quotidien. C’est la partie la plus importante de l’ouvrage, avec 6 chapitres sur 90 pages. Le chapitre 4 ouvre le bal avec les commandes de base, en allant plus loin que ce que nous avons vu au chapitre 3, c’est à dire créer de nouvelles versions, des branches, supprimer et renommer. Bref, tout ce que l’on peut faire individuellement sur un fichier. C’est bien écrit et décomposé : le débutant trouvera son bonheur pour bien débuter. La gestion des branches est un sujet qui arrive très vite, et c’est abordé au chapitre 5. De mon point de vue, sans couvrir toutes les possibilités, on va plus loin que les besoins quotidiens, avec le cherry picking et le renommage de branches. Le « merge manuel » est même abordé ! Étonnement, il n’y a pas trace du rebase !

Continuer à lire « Note de lecture : Pragmatic Version Control, using Git, par Travis Swicegood »

Note de lecture : The Value Flywheel Effect, par David Anderson with Mark McCann & Michael O’Reilly

Note : 9 ; Agile sous steroids! Book of year 2023 !

Est-il possible de créer un cadre de fonctionnement des projet IT où le facteur limitant devient la capacité du métier à avoir des idées assez rapidement ? C’est bien évidemment le sujet du présent ouvrage. Le « volant d’inertie » qu’évoquent les auteurs est un cycle en 4 parties qui forme la structure du livre. Pour donner l’effet d’accélération promis, ils s’appuient principalement sur deux outils. Le premiers est méthodologique: ce sont les « Wardley Maps » qui permet de définir une trajectoire fonctionnelle et technique. Le second est technique : c’est le Serverless dans l’environnement Cloud.

Le texte est structuré en 5 parties : les 4 phases de la roue d’entrainement précédé d’une introduction. Au total, ce sont 250 pages hors annexes structurés en 20 chapitres. La première partie « starting the expedition » compte 4 chapitres sur 60 pages et sera majoritairement consacré à la présentation des Wardley maps. Mais le premier chapitre sera l’introduction de l’introduction, avec une vue générale des 4 phases de la roue. Un chapitre honnête.

Les chapitre 2 et 3 sont consacrés à la Wardley map. Le chapitre 2 en est l’introduction, balayant tout d’abord les différentes approches de mapping stratégiques : OKR, business canvas, 6 pager, etc. Le chapitre 2 présente les principes généraux sans rentrer dans la pratique, mais nous gratifie du Wardley Map Canvas qui, à l’image d’un business canvas permet de cadrer le sujet. C’est le chapitre 3 qui développe la mise en œuvre en dévoilant progressivement les différents concepts. C’est une excellente introduction à l’outil. Le chapitre 4 qui clôt cette première partie via une mise en œuvre illustrée au travers d’un dialogue qui complète parfaitement le chapitre 3.

Continuer à lire « Note de lecture : The Value Flywheel Effect, par David Anderson with Mark McCann & Michael O’Reilly »

Note de lecture : Becoming Agile, par Greg Smith & Ahmed Sidky

Note : 2 ; Une agilité vraiment plus qu’imparfaite, pour un monde imparfait ?

Cet ouvrage prenait la poussière sur mon étage depuis un bon moment. Il était temps de s’en occuper. J’ai passé depuis un bon moment le besoin de compulser des livres permettant de découvrir l’agilité. J’ai même passé depuis longtemps le besoin de voir comment un auteur aborde le sujet par simple curiosité. Disons que je me suis livré à cette lecture par simple distraction ! Ce sera probablement la dernière fois.

Avec 330 pages sur 23 chapitres découpés en 8 parties, le texte est beaucoup plus conséquent que ce à quoi on pourrait s’attendre. Et l’on met plus de temps qu’initialement prévu pour en venir à bout, malgré son côté « pour débutants ». La première partie pose quelques fondamentaux et n’occupe que 2 chapitres pour un total de 25 pages. Les 16 pages du premier chapitre nous exposent les fondamentaux classiques : valeurs agiles, manifestes et principes agiles. Auxquels s’ajoutent quelques mots sur la différence entre l’approche agile et le « plan-driven ». En vérité ce chapitre est plutôt bon. Le second chapitre nous présente le fil rouge du livre : Acme Media. En principe j’aime bien avoir une illustration « fil rouge », mais aussi bien l’exemple choisi que la manière de l’utiliser au fil des chapitres ne sont particulièrement bons.

La seconde partie « getting starting » est bien plus conséquente, avec 7 chapitres sur 90 pages. Les 15 pages du chapitre 3 « are you ready for agile ? » nous livrent un panorama des méthodes agiles à date, mais où l’auteur ne s’engage guère. Toutefois les caractéristiques nous permettant de privilégier un framework plutôt qu’un autre mérite un peu d’attention. Le « readyness assessment », sujet du chapitre 4, va plus loin en nous proposant une véritable grille d’audit que l’on doit à Ahmed Sidky. Même si j’ai moi-même ma propre grille d’audit, l’approche prête le flanc à critique, surtout quand, comme ici, elle est assortie de calculs de scores avec pondérations donnant une fausse impression de précision… Le chapitre 5 est très court, il nous donne quelques voies pour attaquer les exécutifs de la société et obtenir leur support dans une transformation agile. Le propos reste assez superficiel.

Continuer à lire « Note de lecture : Becoming Agile, par Greg Smith & Ahmed Sidky »

Note de lecture : Agile Software Development 2nd edition, par Alistair Cockburn

Note : 6 ; Ô combien austère…

Cette seconde édition de l’ouvrage de référence d’Alistair Cockburn a pris beaucoup d’embonpoint depuis la première. Il accuse 380 pages sans les annexes et ces dernières pèsent 80 pages à elles-seules. Au-delà du volume lui-même, le texte s’avère, comme nous le verrons, très dense. La mise en page sur 2 colonnes assez rare pour ce type d’ouvrage ajoute encore à cette impression. Mais surtout, ce n’est pas un texte qui s’adresse au débutant, les thèmes et le niveau des réflexions qui sont développées dans ces pages rend le texte bien trop ardu pour le nouveau venu.
L’ouvrage compte 7 chapitres, qu’il faut multiplier par deux. Car, autre originalité, le texte d’origine n’a pas été retouché mais il est doublé d’un texte complémentaire qui forme cette seconde édition, ainsi pour chaque chapitre, nous avons le x.0 qui est le texte original, et le x.1 écrit pour cette seconde édition !

Le chapitre 0 « unknowable and Incommunicable », n’est pas le plus facile à aborder. Le propos est à la frontière de la philosophie. Mais il introduit une notion qui m’et chère : le Shu Ha Ri ! L’auteur présente ce concept comme étant une incarnation des 3 niveaux d’écoute : suivre, se détacher et être fluide. Ce chapitre est suivi d’un très court chapitre « évolutions », où l’auteur revient brièvement sur la notion de Shu Ha Ri.

Les choses sérieuses commencent avec le chapitre 1 « un jeu coopératif d’invention et de communication », probablement l’une des expressions favorites de l’auteur. Le chapitre s’ouvre sur la thématique du jeu. Il peut être à somme nul (donc jeu d’affrontement) ou coopératif, c’est évidemment vers ce second type que l’auteur nous oriente : les jeux dirigés vers un but. En fait, il s’oppose surtout à la vision « engineering » du développement, celle du génie civil par exemple. Ce chapitre a bien sûr droit à son chapitre complémentaire « évolution ». Outre une évocation du craft, ce complément ajoute deux éléments. Le premier est l’évocation historique de l’ingénierie dans le domaine logiciel, qui remonte à 1968. Le second est la mise en contexte du Lean. De mon point de vue, c’est franchement poussif. Ce chapitre 1 sert surtout à pousser la vision de l’auteur, mais je n’y vois guère d’éléments qui font progresser ma manière de voir.

Continuer à lire « Note de lecture : Agile Software Development 2nd edition, par Alistair Cockburn »