Imposer sa volonté aux autres, c’est force. Se l’imposer à soi-même, c’est force supérieure.
Lao Tseu
Note de lecture : MDA en action : Ingénierie logicielle guidée par les modèles, par Xavier Blanc
Note : 7 ; Un très bon livre, pour comprendre les concepts clés de MDA, les métamodèles associés et leurs mécanismes de transformation.
Mon snobisme naturel m’incite généralement à préférer les livres américains à leurs équivalents français. Le fait que je m’intéresse aujourd’hui à un ouvrage bien de chez nous ne doit rien à une quelconque cabale hexagonale, mais bien aux qualités intrinsèques dudit ouvrage.
MDA est un sujet complexe, qui nécessite d’en comprendre les fondements afin de pouvoir saisir les nombreux « buzzwords » que sont OCL, Semantic Actions, et autres CIM, PIM, PSM et MOF ! C’est exactement l’approche de ce livre : après un chapitre de présentation générale de MDA, on aborde tout de suite la pierre angulaire du MDA : le MOF (méta-object facilities) encore appelé méta-métamodèle ! Si il est un sujet ardu dans MDA, c’est bien ce fameux MOF (vous l’avez probablement compris rien qu’en lisant la phrase précédente). Mais l’auteur s’en tire fort bien, de manière exemplaire devrais-je même dire car au chapitre 6, on se plonge même dans la manipulation d’un métamodèle construit à l’aide du framework EMF d’Eclipse (celui-là même qui est au cœur de Rational Software Modeler / Architect) : bravo ! Bien sûr, il vous faudra avoir le goût des métamodèles, mais dans le cas contraire, MDA n’est probablement pas pour vous. UML2 est bien entendu abordé, et si vous n’aviez pas encore compris ce que sont UML infrastructure et superstructure (on ne saurait vous en blâmer) et la fameuse dépendance « merge », l’explication est ici. Je met juste un bémol sur les explications dédiées aux classes du métamodèle UML2 qui sont un peu fastidieuses.
Les standards connexes, si ils sont traités brièvement ne le sont pas moins clairement, avec une mention spéciale pour le traitement de XMI et DI (diagram interchanges) ce dernier sujet n’étant même jamais abordé dans les autres textes. De même, si vous êtes noyés dans les problèmes d’incompatibilités de XMI, la réponse est ici. La clé de voûte de MDA, la transformation de modèles n’est pas en reste, puisque l’auteur développe les 3 approches possibles : transformation par programmation, par « templates » et par règles de programmation, la 1ère et le 3ème approche étant par la suite illustrés dans la prise en compte des plates-formes d’exécution, J2EE et PHP respectivement, la transformation entre 2 métamodèles différent (car l’auteur présente un métamodèle PHP simplifié pour l’occasion) est carrément la cerise sur le gâteau ! On est pas loin du tour de force.
Sur le fond, l’approche de l’auteur (fusion des informations de transformation avec le modèle) s’oppose avec l’approche de Kleppe & Warmer qui est de séparer les informations de transformation du modèle. Personnellement je préfère cette dernière approche. Cela ne retranche rien à la qualité de cet ouvrage, que je conseille à la condition que vous recherchiez l’approche « en profondeur » et soyez friand de métamodèles !
L’étude cas et la présentation de deux outils MDA (Rational Software Architect et Objecteering MDA Modeler) ne sont pas la meilleure partie de l’ouvrage, mais elles complètent utilement celui-ci en donnant une illustration concrète.
Voilà donc un livre solide et complet sur MDA. Il requiert un peu e motivation pour aborder le sujet sous l’angle métamodèle, mais il équilibre de façon fort heureuse les principes et la pratique, le tout dans un volume raisonnable, puisque le livre compte 260 pages.
Référence complète : MDA en action : Ingénierie logicielle guidée par les modèles – Xavier Blanc – Eyrolles 2005 – ISBN : 2-212-11539-3
On fait la guerre quand on veut, on la termine quand on peut.
Nicolas Machiavel, in Le prince
Note de lecture : Succeeding with Agile, Software development using Scrum, par Mike Cohn
Note : 8 ; Réussir la transition vers l’agilité
En quelques années et avec 2 livres remarquablement écrits, Mike Cohn s’est imposé comme l’in des leaders du mouvement agile. Voilà donc un livre qui pouvait difficilement passer inaperçu au sein de la communauté !
Globalement, le livre est assez pesant, dans tous les sens du terme : avec ses 450 pages, d’abord, ensuite parce qu’il est composé presqu’exclusivement de texte. Ce n’est pas un texte qui s’avale en un week-end ! Heureusement, Mike Cohn sait écrire et il fait mieux qu’aligner des platitudes, mais je pense quand même que la présente prose n’est pas aussi efficace que celle de l’excellent « agile estimating and planning ». C’est aussi que j’attends beaucoup d’un auteur capable de délivrer un livre d’excellente qualité.
L’une des premières impression qui m’est venue à l’esprit, est le parallèle entre ce livre et celui de Craig Larman « agile & itérative development ». Le livre est divisé en 5 parties, il nous faut bien les passer en revue, car le contenu s’avère au final plutôt riche !
La première partie « getting started » compte 5 chapitres qui totalisent 92 pages. Ce n’est hélas pas la meilleure partie de l’ouvrage. Un large focus est mis sur les communautés de transition vers Scrum, sujet qui m’est apparu abstrait et hélas peu convaincant. Cette première partie se termine sur le choix du projet pilote. Certainement cela s’adresse à ceux qui ont ce choix, donc un public assez restreint pour autant qu’il existe. Heureusement, les parties suivantes reprennent du poil de la bête.
La seconde partie adresse les individus. Longue de 80 pages, elle compte 4 chapitres. Mes deux chapitres préférés sont le chapitre 6 sur le traitement des résistances au changement : agrémenté d’exemples, j’ai trouvé le tour d’horizon complet et pertinent. La façon d’adresser les différents types de résistances est aussi fort judicieuse. J’ai également apprécié le chapitre sur le changement des rôles, il va plus loin que le simple « oubliez ce qui existait avant ». Le rôle du « functionnal manager, par exemple, simplement méprisé par la littérature agile en général, est bien pris en compte.
Avec près de 150 pages et 7 chapitres, la 3ème partie consacrée à l’équipe est la plus longue du livre. Elle traite à la fois la structure de l’équipe et les pratiques de Scrum. Il s’agit justement du chapitre le plus « Scrum » du livre, et l’auteur y livre sont point de vue subjectif sur nombre de pratiques Scrum. Bien que n’étant pas en accords avec tous les points de vue de l’auteur, je n’en considère pas moins cette partie extrêmement riche : elle nous guide littéralement vers la mise en place de Scrum. A noter le chapitre sur la planification qui est un résumé du livre précédent de l’auteur … et une invitation à lire celui-ci !
La quatrième partie est consacrée à l’application de Scrum aux organisations. J’avoue m’être moins intéressé à cette partie qui ne fait pas partie de mes préoccupations. Les 100 pages découpés en 4 chapitres de cette partie évoquent surtout Scrum appliqué en équipes multiples, la coexistence avec d’autres approches et toutes ces sortes de choses..
La cinquième partie a forme de conclusion, avec ces 2 chapitres et ses 20 pages. L’auteur nous signifie simplement qu’on n’est pas au bout du chemin. On ne l’est jamais. On y voit quels outils utiliser pour s’évaluer et quels horizons il reste à explorer.
Comme je l’ai dit au début, le livre est assez lourd, parfois fastidieux à lire. Néanmoins il n’en reste pas moins un ouvrage majeure de cette littérature Scrum encore naissante. Et je pense qu’il le restera. Comment, vous ne l’avez pas encore commandé ?
Référence complète : Succeeding with Agile, Software development using Scrum – Mike Cohn – Addison Wesley 2010 – ISBN : 0-321-57936-4 ; ISBN13 : 978-0-321-57936-2
Note de lecture : Software Development for Small teams: A RUP centric approach, par Gary Pollice, Liz Augustine, Chris Lowe & Jas Madhur
Note: 2 ; « J’écris un programme avec 3 potes, et j’en profite pour écrire un bouquin là-dessus ».
On pourrait presque s’écrier : à l’arnaque ! On n’en est pas loin, et une note de « 2 », c’est plutôt bien payé. Mais commençons par le commencement. Le livre ne porte pas sur l’adaptation d’UP aux petites équipes, mais d’un seul et unique projet sur lequel les auteurs ont essayé UP, c’est donc d’avantage une étude de cas qu’une synthèse d’experts. D’ailleurs, en fait de projet, il s’agit plutôt d’un développement fait en marge de l’activité professionnelle des auteurs, on est donc très loin des conditions normales d’un projet, mais par contre très proche des conditions de développement en « open source », ce qui n’est malheureusement pas identifié, et devrait être valorisé dans le titre. Il y a bien peu de chose à retirer de cet ouvrage ; les conditions de projet ne sont pas là, l’utilisation d’UP est plus expérimentale qu’autre chose, l’outillage employé (et éhontément promu dans le texte) inapproprié n’était-ce le fait que les auteurs les connaissent parfaitement et en disposent gratuitement. Une fois que l’on a lu cela, on peut à juste titre se dire que l’on peut tous se mettre à écrire son livre.
Les 2 seuls points intéressant sont la description du développement de type open source / distribué et l’aspect « post mortem » particulièrement bien abordé. En bref : ne perdez pas votre temps sur ce bouquin.
Référence complète : Software Development for Small teams: A RUP centric approach – Gary Pollice, Liz Augustine, Chris Lowe & Jas Madhur – Addison Wesley / O.T. series 2004 – ISBN: 0-321-19950-2
L’art de la guerre, c’est soumettre l’ennemi sans combat.
Sun Tzu, in L’art de la guerre
Les vertus de l’émergence
Pour ceux qui ont raté mon Lightning Talk lors du Scrum Day (et ils sont très nombreux) et qui le regrettent (ils sont déjà beaucoup moins nombreux), voici cette présentation non plus sous forme de “show” mais sous forme d’article !
Si ce papier reprend le fond et le plan de la présentation de 10 minutes, la forme est sensiblement différente. j’espère seulement que vous prendrez autant de plaisir à le lire que j’en ai eu à l’écrire !
Laissez-moi votre avis !
Voici également le lien vers ce papier dans Issuu
(Source: http://static.issuu.com/)
Rencontre avec Bertrand Meyer
Ce 9 Mai, Valtech nous avait invité à rencontrer Bertrand Meyer. Figure emblématique de l’objet à la fin des années 1980 / début des années 1990, j’avoue que je n’avais plus entendu parler de cette sommité depuis de nombreuses années. L’objet s’est effacé du devant de la scène dans la seconde moitié des années 90 tandis que le Web tractait toute l’attention, et le nom du créateur d’Eiffel a disparu des titres.
C’est donc avec grand plaisir que je suis venu l’écouter, entendre parler d’objet à nouveau et en savoir plus sur ses sujets d’investigation d’aujourd’hui.
Un peu de Biographie
Diplomé de Polytechnique (X-Telecom), Bertrand Meyer a rejoint la direction des études d’EDF en 1974. Parti pour un an en Californie, à Santa Barbara, il y restera quatre, entre 1983 et 1986. Il y rencontrera des sommités de l’informatique, tel que Donald Knuth, mais il créera surtout le language Eiffel
Depuis 2001, Bertrand Meyer occupe une chaire de professeur à l’EPFL de Zurich, où il succède à Niklaus Wirth, le créateur du language Pascal.
Parlons maintenant d’Eiffel
Pour débuter, Mr Meyer nous propose de commencer… par évoquer les points négatifs !
Les points négatifs
- Eiffel n’est supporté par aucun acteur majeur de l’industrie. C++ Le fut par AT&T, puis par Sun. Java l’a été par Sun et désormais par Oracle.
- Mais il s’est fait sa place chez certains industriels qui lui sont fidèles.
Il s’agit d’une petite communauté. Toutefois cette communauté n’a jamais cessé d’exister depuis 25 ans. Donc si ce mouvement est discret il est solide.
- De manière assez curieuse, après avoir essuyé les reproches d’être un langage “trop jeune”, Eiffel est presque directement passé au statut de “legacy” !
Pas de phénomène de mode autour du langage. A aucun moment, il n’a eu la réputation d’être le langage “dans le vent”. Absence de composants réutilisables. Ce dernier point est paradoxal, car le langage a été imaginé et créé au départ avec cette finalité en tête.
- Aujourd’hui les librairies existent mais restent peu nombreuses comparées aux standards du marché.
- Mais le langage est simplement interfaçable vers le C et le C++ (le compilateur fonctionne en “C front”). L’interfaçage se fait également sur la machine virtuelle .NET de Microsoft. L’interfaçage vers Java est possible, mais difficile.
Les points négatifs … qui n’en sont pas
- “Cette fonctionnalité finira par arriver dans mon langage favori”. Les ajouts de fonctionnalités après coup dans les langages s’avèrent générallement boiteuses. Par exemple les “code contract” de .net fonctionnent comme des pièces rapportées.
- “Il n’y a pas de programmeur Eiffel”. Eiffel n’est pas une religion. Tout développeur aguerri à l’objet peut se mettre aisément à Eiffel. Il est apte à être pris en main par des débutants, plus qu’il ne s’avère possible avec C++ qui est un langage difficile à maîtriser.
- Pas de covariance pour l’instant. Il s’agit d’un problème avec le système de type sui sera résolu bientôt.
- Pas fait pour le Web. Là aussi il s’agit d’un point en cours de résolution. Le framework EWF adressera cela.
Ce pour quoi Eiffel est fait
- Il ne cible pas les réalisations “quick and dirty”. Les langages orientés script tels que Perl et Python sont mieux ciblés pour cela.
- Il ne cible pas non plus le temps réel: la présence d’un garbage collector est une source d’alea trop importante pour répondre aux exigences du temps contraint
Et les types de développements ?
- Les développements “casual” ne sont pas non plus le coeur de cible du langage (cf le “quick and dirty”)
- Le développement professionnel en entreprise est clairelment la cible du langage. C’est par ailleurs la très grande majorité des développements informatiques.
- Les développements critiques (money critical, life critical) : pas non plus la cible privilégiée du langage, malgré la présence de fonctionnalités adaptées (typage forts, contrats).
Quels sont les argumentaires d’Eiffel ?
Par rapport à sa cible, ce sont les arguments liés à la qualité sur le long terme:
- Extensibilité
- Fiabilité
- Scalabilité
- Portabilité (grâce au compilateur “C front”, il a le niveau de portabilité du C sous-jacent).
- Intégration méthode / langage. Nous reviendrons sur ce point.
Cet argumentaire qualité passe hélas peu. Il est pourtant très aligné sur les principes sous-jacents à l’agilité au niveau du code, selon l’analyse qu’en fait Bertrand Meyer, suite à sa formation “Scrum Master”.
Alors quels sont les projets classiquement dévolus à Eiffel ?
- Ceux pour lesquels tout le reste n’a pas marché !
- Ceux qui sont soumis à des évolutions fréquentes.
- Ceux pour lesquels il y a un “champion local” supportant ce choix.
Et justement, ces développeurs à quoi ressemblent-ils ?
- Ce sont tout autant des concepteurs que des codeurs … et certainement pas de simples codeurs: comme dans tout langage objet, les principes de conception sont liés au langage, mais pour Bertrand Meyer, c’est encore plus le cas avec Eiffel !
- Ce sont des développeurs dont la volonté de se perfectionner est plus importante que celle de suivre le plus grand nombre.
- Il semblerait aussi que la pratique d’Eiffel rende beau et donne un charme irrésistible auprès des femmes ! Et voilà : Bertrand Meyer nous a pris par surprise, car sous une apparence disons classique, le créateur d’Eiffel a un sens de l’humour tout à fait aiguisé, et il nous délivre ses traits sous un air pince sans rire redoutablement efficace !
La réalité d’Eiffel aujourd’hui
Eiffel est à la fois une méthode, un langage et un environnement.
En tant que méthode
Eiffel suit les principes de la conception orientée objet, tels du moins que son auteur les a décrits dans son ouvrage disponible dans toutes les bonnnes librairies.
Eiffel suit le principe du “single model”, c’est à dire que le code du langage porte le code d’exécution, mais aussi des informations d’analyse, comme celles concernant les pré/post conditions et les invariants.
L’approche orientée obets est l’axe principal (unique ?) de l’approche d’Eiffel, la méthode (et le langage) supportent donc le paradigme des types abstraits de données, ce qui signifie :
- Une description abstraite des propriétés des opérations.
- Une organisation des types en hiérarchies supportant le polymorphisme (principe de substitution de Liskow).
En tant que language…
Eiffel a été normalisé par l’ISO en 2006. L’implémentation du compilateur est donc ouvert à la concurrence, du moins en principe.
La classe est le seule mécanisme de modularisation. Pas de “package”, de “namespace” ou de “module” !
Par ailleurs, Eiffel est un des rares langage qui supporte l’héritage multiple, position que Bertrand Meyer défend avec ardeur. Si je le suis sur ce terrain, l’exemple qu’il nous a présenté ne m’a pas paru terriblement percutant: le cas du vélo qui hérite de “véhicule” et de “Liste” me semble boiteux, car ces deux abstractions sont de niveaux très différents. Ainsi la liste devrait être un simple élément d’implémentation dans le vélo…
Eiffel supporte aussi depuis le départ la notion de générique. Contrairement à C++ et surtout par rapport à Java, cette fonctionalité n’est pas une pièce rapportée … surtout quand elle est aussi faible que le “type erasure” de Java !
… Toujours vivant !
Le langage est désormais “void safe”. Cet ajout arrivé il y a 6 ans interdit le déréférencement de pointeurs pouvant être nuls ! Et ceci est même vérifié à la compilation.
Les agents. Il permet de construire des clases qui sont des “observer” du pattern MVC. D’autres classes pouvant évidemment publier des évènements. C’est le MVC intégré dans le langage !
En tant qu’environnement
Eiffel Studio est le standard “de facto” du langage. Il intègre 2 compilateurs:
- 1 compilateur “C front” qui est le compilateur historique d’Eiffel. Ce passage par le C est le couche qui assure au langage sa portabilité, comme je l’ai évoqué précédemment.
- Un compilateur sur la machine virtuelle .NET de Microsoft.
Le compilateur utilise la technique dite de “la glace fondue”, en fait une compilation incrémentale qui rend les temps de compilation non pas dépendants de la taille du projet, mais de l’importance des changements depuis la dernière compilation.
Design by contracts
L’un des apports originaux (repris depuis par d’autres langages) est la notion de contrats. Ceux-ci sont intégrés au code selon le principe du “modèle unique” que nous avons évoqué plus haut. L’environnement dispose quand à lui d’outils pour extraire ces informations à différents niveaux (modèle, documentation, tests…). Il y a 3 types de contrats:
- Les préconditions : Il s’agit des conditions que l’apellant doit respecter avant l’appel à la méthode.
- Les postconditions : Il s’agit des conditions que l’apellé doit respecter avant de rendre la main.
- Les invariants: Ils doivent être respectés à tout moments..
Dans le cas du polymorphisme, les préconditions appartenant à l’abstraction sus-jacente doivent être respectées au moment de la liaison tardive entre appelant et apellé.
Les contrats permettent de vérifier les domaines de validité des paramètres en entrée, de valeurs de retour en sortie et les conditions de stabilité des objets. Dans le cas de l’explosion d’Ariane 5, la vérification du domine de validité des paramètres d’entrée aurait suffit à prévenir l’explosion de la fusée !
En développement, la violation de contrat nous emmène directement dans le debugger, celui-ci précisant la nature du contrat non respecté et le contexte.
Eiffel et les tests unitaires
Bertrand Meyer s’inscrit dans la logique de mise en place des tests unitaire instillée par les pratiques agiles et plus particulièrement TDD ! Cependant il juge que ceux-ci souffrent encore de points faibles, parfois simplement passés sous silence dans la littérature:
- Génération des tests unitaires: les tests passants et surtout les tests non-passants.
- L’enrichissement des tests unitaires sur la base des échecs d’exécution.
- La minimisation des tests afin d’en optimiser l’exécution.
L’environnement Eiffel propose un outil à cet effet nommé Autotest qui permet la génération des tests à partir de contrats, mais égallement leur enrichissement sur la base des échecs d’exécution. Bertrand Meyer n’a rien dit sur le volet de la minimisation, j’imagine donc que c’est toujours un sujet en cours de travail.
Le parallélisme avec SCOOP
Il s’agit d’une nouvelle extension d’Eiffel : Simple Concurrent OO Programming. Il s’agit bien d’une extension car au moins un nouveau mot-clé (separate) est introduit dans le langage avec SCOOP. Le problème de la concurence n’est pas nouveau et nous savons tous qu’il n’est pas simple à adresser. Son importance augmente pourtant de manière importante, avec la progression des processeurs “multi-coeurs”.
SCOOP met en avant les notions d’action, d’asynchronisme et surtout de “région”. SCOOP prend en charge les mécanismes de synchronisation de bas niveau afin de permettre ce que Bertrand Meyer juge important : pouvoir raisonner sur les programmes.
Le principe de base de SCOOP est le “wait rule”: une action ne démarre pas tant que toutes les ressources nécessaires ne sont pas disponibles.
Les développements en cours
Depuis qu’il a repris en 2001 la chaire de professeur de Niklaus Wirth, Bertrand Meyer poursuit ses travaux autour d’Eiffel:
- La notion de “preuve” formelle, et de vérification statiques ou dynamiques des programmes.
- La persistence
- Le “cloud based developpement”. Dans cet environnement, le VCS (ou même le DVCS à la Git) disparait. Les changements se font et sont répercutés en temps réel, à la Google doc.
- EVE: une évolution de l’environnement Eiffel permettant la vérification des programmes minute par minute.
- Autofix, qui l’étape suivant d’Autotest: l’idée ici est de proposer des corrections automatiques des programmes pour les cas simples. Actuellement le ratio de succès de cet outil est de 2/3, testé sur les correctifs apportés au fil du temps sur les librairies Eiffel elle-mêmes.
En conclusion
Eiffel existe, il est toujours en cours d’évolution. Mais il ne deviendra jamais “mainstream”. L’auteur l’avoue et s’en accommode. Certaines choses qui sont acquises dans des langages modernes : la covariance, la présence de frameworks Web sont encore très récentes ici ou en cours de développement. Le langage reste ancré sur ses choix initiaux : purement objet, sans mécanisme de modularité à grande échelle ni intégration de paradigme tiers comme la programmation fonctionnelle. Ces choix ont nécessairement un impact pour rendre le langage attrayant pour le plus grand nombre, mais c’est une bataille que Bertrand Meyer ne cherche plus à mener.
Paradoxalement, cette position de niche lui confère certains avantage, comme la possibilité de ne pas rester fixé sur la stricte compatibilité ascendante lors des évolutions du langage. Et si la communauté est petite, elle est très fidèle à Eiffel. Car le langage reste remarquable, certes doté d’un ecosystème de librairies sans commune mesure avec Java, mais avec un design de base qui n’a rien à lui envier, bien au contraire !
Si vous voulez aller de l’avant avec Eiffel, vous pouvez rejoindre le Groupe des Eiffelistes Francophones (la page Google Group est ici). Merci à Jocelyn Batton de l’avoir créé !
Mon père était un chercheur d’or.
L’ennui, c’est qu’il en a trouvé.
Jacques Brel
Scrum Night chez Google : appel au vote des animations !
La Scrum Night chez Google approche ! Nous avions lancé un vibrant appel pour des animations d’ateliers le 19 Avril. Celui-ci a été entendu : 15 propositions d’ateliers ont été postées sur IdeaScale.
Les propositions d’atelier sont maintenant fermées ! Elles sont aujourd’hui au nombre de 15. Un grand merci à tous ceux qui se sont lancés pour proposer une animation !
Mais il reste encore une chose à faire : voter, et vous avez jusqu’au mardi 15 Mai au soir pour cela !
Attention, certains ateliers n’ont été proposés que récemment, cela se reflète dans le niveau de leur vote. Mais tout peut changer maintenant : vous n’avez été que peu nombreux à vous exprimer jusqu’à présent. Il est temps de faire connaitre votre avis.
Ne votez pas pour trop de sessions. L’agenda n’est pas encore défini, mais vous n’aurez probablement l’opportunité de n’assister qu’à deux ateliers lors de cette soirée. En limitant vos préférences disons aux 3 ateliers qui attirent le plus votre intérêt, vous améliorez vos chances de les faire sortir du lot !
Pour épicer le tout, IdeaScale propose un bouton “en désaccord”. Alors c’est vrai que l’on a souvent des scrupule à faire cela. Mais c’est le jeu, et c’est votre super-pouvoir de permettre non seulement de faire progresser les sujets que vous appréciez mais aussi de faire baisser ceux que vous n’aimez pas (ou simplement que vous ne souhaitez pas voir) !
Les votes obtenus par les différentes animations seront un élément déterminant dans le choix de ce qui sera retenu dans l’agenda définitif de la soirée !
Attention, le temps passe vite, ne remettez pas à plus tard ce que vous pouvez faire dès maintenant :
Software Freethinker 
