La conférence ACCU 2008

La keynote du jour "Value delivery for Agile environments" est présentée par Tom Gilb, un pionnier des méthodes de développement itératives. Il a été la source d'inspiration de nombreuses méthodes Agile.

Il nous a présenté sa méthode, basée sur SCRUM. Ce qu'il reproche aux méthodes Agile : c'est leur manque de mesure de valeur. Selon lui, le burn rate ne sert à rien pour appréhender la valeur ajoutée que va obtenir l'utilisateur final. Il cherche à tout quantifier. Y compris par exemple, la robustesse (qu'à la réflexion je serai bien en peine de mesurer) ou d'autres qualités trop générales afin de pouvoir leur affecter un coût et une incidence sur d'autres mesures du projet.

Il crée avec ceci des tableaux d'estimation d'incidence qui permettent de mieux cibler les travaux à entreprendre afin de délivrer le maximum de valeur ajoutée à toutes les parties prenantes (stakeholders) au moindre coût.

Je suis resté sceptique par le travail à accomplir, qui fait ressembler toute cette étude préalable à un bon vieux gros waterfall. Et les commentaires des autres orateurs du jour m'ont rassuré sur ce point. Avec sa critique trop virulente des méthodes Agile, j'ai l'impression qu'il s'est mis toute l'assistance à dos (350 personnes !).

La séance suivante est présentée par Gail Ollis : "Santa Clauss and other methodologies." Elle nous a rappelé deux méthodologies qu'elle a utilisées il y a une quinzaine d'années : RTSASD et GDPM. Ces méthodes qui étaient des réactions compréhensibles dans un contexte waterfall, mais qui sont toutes deux (heureusement) passées dans les oubliettes de l'histoire de la programmation.

Quelques idées à retenir.

- "L'intérêt d'une méthodologie est inversement proportionnelle à sa généralité" (Jackson, 1995)

- L'histoire du canard en plastique (cela nous est tous arrivé) : on butte sur un problème pendant des heures sans arriver à le résoudre, puis on se décide à aller en parler à un collègue pour qu'il nous aide. Et là, avant même que ce dernier ne dise un seul mot, la solution nous apparaît, très clairement. On aurait pu en parler à une plante verte ou à ... un canard en plastique, le résultat était le même.

Elle compare enfin les différentes méthodologies existantes pour le développement logiciel avec les différentes thérapies psychiatriques. C'est bien d'en connaître le plus possible pour pouvoir prendre ce que l'on veut, ce qui va nous servir dans chacune d'elles, tout en sachant pourquoi, mais surtout de savoir pourquoi on ne veut pas de tout le reste.

J'ai débuté l'après-midi par un atelier : "Tools, Frameworks and Libraries: the Devil's work or Manna from Heaven?". Le but était par petits groupes de lister les outils que nous utiliserions et ceux que nous n'utiliserions pas pour réaliser un des petits projets proposés.

Le groupe auquel j'ai participé était très homogène. Nous n'avons eu aucun mal à lister nos outils : Linux (toutes distributions), gcc, subversion, log4cplus, gtk/wxWidets, sqllite, buildbot et make (autotools). C'est ce dernier qui serait le premier candidat pour être remplacé par un meilleur outil. Par contre nous n'avons choisi aucun des projets proposés, ces derniers étant trop distribués pour être faits en C++.

De cette liste finale, nous avons dû retirer quelques candidats suite à l'intervention du meneur, au milieu du jeu, pour nous annoncer que nos managers avaient un budget très serré. Ce fut le cas de Qt, mais aussi des compilateurs comeau ou Intel. Enfin nous est apparu ce qui nous manquait : un vrai bon débuggeur pour Linux. Ce serait notre petit projet à faire en six semaines (MDR)

Quelques bonnes réflexions qui ont fait l'unanimité : pas de distribution Linux imposée (cela nous permet tout de suite en fonction des goûts de faire des tests sur plusieurs environnements) et par dessus tout pas d'éditeur imposé (il fallait éviter une nouvelle guerre de religions emacs contre vim), en effet, pourquoi imposer un outil pour écrire du texte ? Ce serait d'emblée se mettre à dos deux développeurs sur trois pour rien.

Les autres groupes on plus joué le jeu des projets et ont donc proposé des solutions distribuées, C#, Python ou PHP sur serveur Apache avec des bases de données PostgreSQL ou Oracle. Un point pour C#, Python, PHP : la disponibilité de nombreuses librairies libres. Un seul des groupes vantait "l'achat de bonnes librairies de bon code." Ce à quoi d'autres ont pu répliquer qu'ils avaient déjà édité des librairies en binaire afin de fixer certains bugs !

Dernière présentation de la journée par Pete Goodliffe: "A Tale of 2 systems." Rien de nouveau dans cette présentation de deux projets auquel il a participé, semblables dans leur environnement cible et dans leur domaine d'activité. Simplement l'occasion de réfléchir à notre métier et une idée directrice : c'est le design du logiciel qui fait sa qualité.

Le premier projet montrait ce qu'il ne faut pas faire. Un projet qui a été démarré dans une équipe où chaque personne cherchait à s'accaparer le code. Il a évolué par ajouts successifs sans à aucun moment faire de redesign salutaires qui auraient pu rembourser cette "dette technique" qui accumulait ses intérêts (j'aime beaucoup cette image).

L'analogie avec une ville peut surprendre mais permet de mettre en lumière le manque de structure, de voies de communications adaptées qui créent des embouteillages. Un manque d'élégance et de cohésion qui demande des dons d'archéologie logicielle pour essayer de comprendre le fonctionnement et espérer pouvoir résoudre quelque bug ou ajouter quoi que ce soit.

L'autre projet a été démarré dans une équipe où chacun se sentait responsable de l'ensemble du projet. Le design haut niveau reste le seul document qui ne soit pas du code : il tient sur une page et consiste en deux diagrammes de quatre ou cinq blobs. Mais cette présentation simple permet au développeur d'appréhender très facilement et rapidement le projet. Il sait tout de suite où rajouter telle nouvelle fonctionnalité, dans une hiérarchie de fichiers claire. Chaque développeur se sent responsable du design.

Pour terminer, le design n'a pas d'implications que sur le logiciel. Il influence aussi le moral et le turn over des programmeurs, la satisfaction des clients, du management, du département marketing.

Une réflexion pour finir : "Si vous apprenez quelque chose de vos erreurs, c'est bien. Si vous apprenez quelque chose des erreurs des autres, c'est mieux."

La keynote du jour est présentée par Simon Peyton Jones : "Caging the Effects Monster: the next decade's big challenge." C'est le créateur du langage Haskell : un langage de programmation fonctionnelle. Comme nous sommes habitués aux langages impératifs, c'est une toute autre histoire qu'il nous propose. Plus de commandes pour définir le flux de contrôle, ici n'existent plus que des expressions qui définissent le flux de données.

Haskell et les langages de programmation fonctionnelle reposent sur la pureté (purity) des fonctions : elles n'ont pas d'effets secondaires. Les mêmes valeurs en entrée produiront toujours les mêmes valeurs en sortie. Ainsi tout le programme peut être optimisé, parallélisé sur plusieurs processeurs.

Une analogie avec le C++ est possible : en C++, on ajoute const pour dire qu'une fonction est pure. En Haskell, toutes les fonctions sont pures par défaut. Il faut préciser quelles fonctions ne le sont pas : celles qui réalisent des entrées et sortie par exemple. Ca me rappelle une réflexion que j'avais eue il y a bien longtemps : je pensais qu'il aurait mieux valu inventer le mot clé nonconst en C++ ...

Enfin voila. Il y a quelque chose dans l'air avec Haskell et les autres langages de programmation fonctionnelle (OCaml, Erlang, PLINX ...). En ces périodes de multiplication des coeurs sur nos machines, trouver une nouvelle manière de les utiliser est peut-être le futur.

Ensuite, Kevlin Henney : "The Selfish Object". Une suite d'idées pour aider au design des objets. Les trois qualités qu'un objet doit avoir : "ignorance, apathie et individualisme." Avec cette série de points de vue décalés comme celui-ci qui m'a bien fait marrer : "La terre est peuplée de choses en métal avec des roues qui se déplacent autour de cubes de bétons et qui ont des trucs roses comme serviteurs."

Difficile de sortir une suite très logique de la présentation très riche. Quelques techniques d'inversion de contrôle, qui permettent de compenser le fait que les diagrammes de classes vont généralement vers le haut alors que les diagrammes de packages vont vers le bas ! Le mot d'ordre général : "Réduire le couplage et améliorer la cohésion", pour éviter "en attrapant la banane, de ramener le gorille avec."

"Parametrize from above." Les paramètres sont là pour cela. Et pas question d'avoir un gros objet de contexte que l'on passe à tout le monde. Non, on passe juste ce qu'il faut, c'est à dire juste ce dont les fonctions ont besoin. Enfin sur le nommage, donner un nom aux classes d'interfaces en fonction de qui va les utiliser et non de qui va les implémenter.

Encore un petit atelier en début d'après midi : "The simplicity workout." Pas question ici d'aller vers le simplisme, non. C'est plutôt un travail en cours sur ce qui fait qu'un programme est simple et élégant.

Quelques exemples de ce qui est simple :

• quicksort tout d'abord, explicable en deux phrases, implémentable en 5 lignes.
• MapReduce de Google, leur algorithme d'indexation.
• La notion de conteneurs et d'algorithmes de la librairie standard C++ aussi.
• UNIX pour ses entrées et sorties de fichiers qui s'appliquent à tout, même à l'écran.
• UNIX encore pour la composabilité avec les redirections, tuyaux et filtres.
• L'interface utilisateur de Google enfin.

Une technique potentielle pour faire du code simple : le développement décrémental. Il consiste à déterminer ce qui est nécessaire et à éliminer le reste. Pas facile. Suite à l'atelier proprement dit, où nous avons dû par petits groupes simplifier de petits programmes ou concepts, nous avons essayé d'établir une liste de ce que nous avions fait pour simplifier.

Les pistes : penser à la totalité du système et ne pas chercher à résoudre trop localement. Ceci nécessite bien évidemment de comprendre ce que fait le programme, mais peut-être aussi de comprendre ce que l'on veut, c'est à dire quel est le problème que le programme cherche à résoudre. Il faut parfois aussi commencer par simplifier avant de pouvoir comprendre, et ne jamais perdre de vue le but lors du refactoring.

Dernière séance par Andrei Alexandrescu : "Memory Allocation: Either Love it or Hate it (Or Think It's Just OK)." L'allocation mémoire fait partie de ces problèmes insolubles, au sens de l'Incomplétude. Étant donné un allocateur, il est toujours possible de trouver un programme avec qui cet allocateur sera pire que tout. L'allocateur optimal universel n'existe pas. Le compromis se trouve entre un allocateur très général et un allocateur très spécialisé.

Windows XP utilise un allocateur de meilleur choix (qui, soit dit en passant, n'est pas meilleur que l'allocateur de pire choix). Linux utilise un allocateur de Doug Lea, la référence des allocateurs, un assez bon compromis. Cela ne sert à rien de chercher à faire un allocateur généraliste : sur 8 projets utilisant un allocateur spécialisé, 6 ont vu une amélioration de performance en remettant l'allocateur par défaut.

Les pistes pour améliorer la performance sont à rechercher en spécialisant l'allocateur pour un programme donné. Il faut d'abord collecter des données, et dans le cas où certaines tailles d'allocations se répètent, il est possible d'utiliser des Free Lists spécialisées. Le reste des allocations pouvant se faire dans des Regions. Le modèle final est une combinaison des deux portant le nom de Reaps.

Pourquoi tant d'intérêt dans l'allocation mémoire ? Tout simplement parce que c'est généralement là où un profileur vous indiquera que votre programme passe la plus grosse partie de son temps.

La journée commence avec celui qui l'a terminée la veille, Andrei Alexandrescu : " May You Live Interesting Times". Il s'agit de C++, pur et dur. Andrei nous montre au travers de la fonction identity, puis des fonctions du test de Stepanov's Litmus : min, swap, et find que le type des variables n'est pas toujours transporté en C++.

En C++98 tout d'abord. Pourtant, écrire une fonction qui renvoie ce qu'on lui donne, "this is not rocket surgery!" :-) Il faut en faire deux, une const et une non const. Mais c'est loin de marcher dans tous les cas ... En C++0x, avec les r-value reference (&&) ce sera beaucoup mieux. Mais il y aura encore des cas où ça ne passera pas.

Pour la fonction min, une nouvelle implémentation a été proposée pour le nouveau standard. Elle fait 175 lignes, déclare 10 types et 12 spécialisations (de templates). Elle a été refusée. Pour swap ce n'est pas mieux. Il est difficile de faire sans copier les valeurs. Cela devrait pourtant être simple, en Haskell, swap tient une demi ligne ! Pour find, aucune amélioration attendue, sinon une syntaxe plus concise (auto) et de meilleurs contrôles (et messages d'erreurs) avec les concepts.

Il y a des experts de classe internationale en préprocesseur (ils maîtrisent l'opérteur ##). Il y a des experts de classe internationale en name lookup (ils connaîssent ce que fait f(x)). Il y a de la place pour des experts de classe internationale en r-value references. De même en concepts.

Ces concepts qu'est ce que c'est ? Personne ne sait encore. Mais les évolutions successives le montrent : les procédures, la pile d'appels, les fonctions qui travaillent avec des fonctions (templates) et les fermetures (closures) qui travaillent avec des données qui n'ont pas encore été définies ont apporté chacun un renouvellement. Le prochain s'appuiera sur les concepts.

Ensuite, un petit atelier : "Managers: What are they good for?" par Allan Kelly. Après une petite présentation s'appuyant sur quelques passages du Mythical Man Month (Brooks, 1975) l'assistance s'est séparée en deux, développeurs d'un côté, managers de l'autre. Et chaque groupe a fait une liste de ce qu'il reprochait à l'autre groupe ...

Les listes étaient remplies de stéréotypes. Mais une idée générale qui émanait de tous les groupes de chaque camp, c'est le manque de confiance. Le principe de Peter a bien sur été rappelé pour l'occasion.

Puis la présentation a repris, sur l'inflation des titres. On colle un titre de manager à n'importe qui de nos jours. Il existe des managers de tout et n'importe quoi. Mais pour les programmeurs, manager, c'est un mot qui pue. Quand une classe s'appelle quelque_chose_manager c'est mauvais signe. Cela signifie que c'est une classe fourre tout dont on ne sait pas bien quel est le rôle.

Pour finir, les groupes de développeurs ont fait une liste de ce qu'ils aimeraient que les managers fassent. De leur côté, les managers ont fait la liste de ce qu'ils aimeraient bien faire (eux-mêmes). Et ces listes étaient assez similaires en fait. C'était le but de la présentation.

Début d'après midi à nouveau avec Tom Gilb : "Designing Maintainability and Adaptibility by Software Engineering: a Quantified Approach." Comment mesurer la capacité de maintenance (maintainability) ? En hardware, on utilise le MTTR (mean time to repair) ou temps moyen pour réparer. Et donc il nous a demandé quels étaient nos MTTR ? Et que ferions nous si nous devions fournir un MTTR de 1 seconde ?

Une partie de la séance a été dédiée à recadrer qu'est ce qu'était l'ingénierie, par rapport à la technique. Il en est ressorti que c'est l'application des principes de la science afin de calculer des prédictions numériques et des mesures basées sur la connaissance et l'expérience. Waouh. Les mesures. Voilà ce qui nous manque dans l'ingénierie logicielle.

Dans deux exemples, il nous a montré des listes d'exigences (requirements) peu recommandables. Pourtant je suis certain d'en avoir déjà vu passer des comme ça : "Rock solid robustness", "user friendly", "easy to maintain" ... Peut-être même d'en avoir écrit ! Bref il faut quantifier, donner une mesure. Et il a inventé un langage pour ça le "planguage".

Il nous a incité à aller lire son papier "Inversion Programming" sur son site (gilb.com) et nous n'avons pas eu le temps de parcourir plus en avant sa présentation. Les 90 minutes étaient écoulées, mais il nous a dit qu'il avait réussi à faire passer son message. Ah bon ?

Fin d'après midi avec Jim Hague et Russel Winder : "To distribute or not to distribute or How to know your DVCS from your VCS."

Petite évolution des systèmes de contrôle de version (VCS), en partant des backups (!) puis de SCCS et enfin RCS, avant que CVS n'apporte l'utilisation concourante et la liaison distante, une étape majeure qui marquera CVS comme une référence dans le contrôle de version. Enfin Subversion qui corrige les défauts de CVS. Mais il est déjà rattrapé, et même dépassé par d'autres : git, bazaar, mercurial, darcs : des systèmes qui n'ont plus de dépôt central. Ceux qu'on appelle des systèmes de contrôle de version distribués (DVCS).

Petit présentation live de l'utilisation de bazaar (bzr) et mercurial (hg). Tous deux ont des syntaxes ligne de commande très proches de CVS (et SVN), à l'opposé de git qui possède 178 commandes distinctes (!) et de nombreuses options pour chacune. Chacun crée un dépôt (ou une branche selon sa terminologie) en local où l'on peut commiter ses changements. On peut ensuite les publier, les transférer vers d'autres. Mais on garde toujours sa branche, son historique en local, tout en ayant la possibilité d'en importer d'autres.

Bazaar est supporté par Canonical Ltd (ubuntu) et vient de passer comme projet GNU. En plus d'être un système VCS complet qui gère bien les branches et les fusions, il a une fonctionnalité très intéressante de pouvoir se lier à un serveur Subversion. On peut ainsi avec un dépôt bzr local, faire des commits locaux, puis pousser ces commits sur le serveur svn immédiatement, ou plus tard.

Mercurial de son côté n'offre pas ce système de liaison. Mais il propose tout le reste, branches et fusions compris. Il a une manière un peu déroutante de présenter les branches, mais les morceaux d'interface graphique que j'ai vus m'ont paru très pertinents. Et c'est peut-être de ce côté qu'il y a quelque chose à aller chercher.

Pour conclure, si Subversion vous va, que vous êtes toujours connectés et que vous pouvez donc toujours accéder au dépôt central, il n'y a pas vraiment de raisons de changer. Mais si vous bougez un peu, que vous souhaitez un peu plus de liberté, sans avoir à passer toujours par le serveur et son cerbère, essayez un DVCS, vous serez comblés.

Dernier jour, Roger Orr : "Seven Deadly Sins of Debugging". There is no silver bullet. Il y aura toujours des bugs, et il faudra toujours débugger. Par contre, il regrette qu'il y ait si peu de livres traitant du sujet : le debuggage. Il nous cite jute un livre récent : "Advanced Windows Debugging". Enfin il fait une analogie entre le debuggage et le travail de Sherlock Holmes, qui consiste à trouver ce qui s'est passé.

Voici donc les 7 pêchés capitaux du débugage.

• L'inattention, parce que nous sommes humains, contrairement à un ordinateur qui ne se lasse jamais (get bored).
• La fierté, bien que vertu du programmeur Perl, nous fait écrire parfois du code trop avancé.
• La naïveté qui nous laisse à penser que cela ne peut pas mal se passer.
• La colère qui brouille notre capacité de jugement et nous fait refuser de voir la réalité.
• La paresse qui nous fait minimiser la portée d'un bug, pour éviter le travail pourtant nécessaire.
• L'accusation (blame) quand chacun s'écrie : "Ma partie fonctionne" ou reporte l'erreur sur l'OS ou le compilateur.
• Le flou, ou l'imprécision quand le rapport de bug indique juste que : "ça plante".

Heureusement pour nous, l'antidote à chacun de ces pêchés existe. Il faut fait preuve d'observation, d'humilité, de sagesse, de patience, de diligence, de responsabilité et de précision. Debugger, ce n'est pas de la magie noire. C'est un art difficile, et on va devoir continuer avec, car cela n'a pas de raisons de s'améliorer.

Ensuite, James Coplien : "Five practical solutions to Agile Myths." Bien que défenseur du manifeste Agile, il nous livre quelques écueils à éviter qui ont été amenés par les méthodes XP et SCRUM. "Agile n'a fait qu'essayer de ramener la programmation à ce qu'elle était il y a 40 ou 50 ans, avant que les managers n'arrive pour gérer le risque."

Le On-Site Customer fatigue l'équipe à force de changements. Les User Stories qui se transforment en vagues requirements. Le Test Driven Development (TDD) fait pour une architecture procédurale qui indroduit un couplage néfaste entre le code et les tests. You Ain't Gonna Need It (YAGNI) aussi.

Les questions ont beaucoup porté sur cette accusation au TDD, mais Cope préfère les Design by Contract (les assertions). Les tests unitaires demandent à peu près autant de code que le code lui-même. Pourquoi est-ce que ayant deux fois plus de code il n'y aurait pas deux fois plus de bugs ?

Il ne faut pas perdre de vue le but. Programmer pour que la barre de JUnit devienne verte n'en est pas un. TDD apporte peut-être des effets positifs à court terme, mais c'est un problème à long terme. Enfin, il a fini en nous disant qu'il ne pensait vraiment que la moitié des choses qu'il nous a dites ... Je n'arrive pas à faire le tri.

Petit supplément. James était au bar de l'hôtel le soir. La discussion était très animée et portait toujours sur ce même sujet. Il a bien précisé que son argumentation était fondée. Il a fait une thèse sur le sujet ("I made my homework. I got a PhD"). Ce que j'en ai compris, c'est que les tests du TDD (et là personne se semblait mettre la même définition derrière) portent sur les interfaces du programme, pas sur sa structure interne. Ou encore que le TDD se base sur des tests d'intégration plutôt que des tests unitaires.

L'après midi présentation par Didier Verna, français, enseignant à l'EPITA : "Performance and Genericity: the forgotten power of Lisp." Tout d'abord, arrêtons de railler les parenthèses. Il nous a montré des morceaux choisi de C++ avec templates et de Lisp, c'est vrai qu'il n'y en a pas un des deux qui soit plus lisible que l'autre ...

Après un petit rappel de tout ce que peut faire Lisp : typage dynamique ou statique, langage fonctionnel et impératif ... Il nous a montré le résultat de ses recherches sur la performance. En comparant les temps d'exécution de routines de traitements d'images à la fois en C et en Lisp, il arrive à la conclusion que le Lisp est aussi rapide que le C. Il faut pour cela bien optimiser le Lisp en aidant le compilateur à faire du typage statique, mais c'est pareil au final. Et donc l'idée serait qu'on peut faire du Lisp sans se soucier de performance. Il faut juste aider un peu le compilateur là où c'est nécessaire.

La deuxième partie consistait en l'utilisation avancée du CLOS, le Common Lisp Object System. Ici, il nous a décrit les multi-méthodes, qui sont plus avancées que les fonctions de classe C++ puisque pouvant être virtuelles sur plusieurs objets à la fois IYSWIM. Puis de là, il a surchargé le mécanisme interne du SLOC afin de rajouter des contrôles pour que toutes les fonctions nécessaires soit bien définies par le programmeur, pour toutes les classes.

Voilà, la journée et la conférence se sont terminées sur une discussion entre quelques orateurs : "State fo the Practice." Leurs réponses en introduction : "On ne se focalise pas assez sur la valeur ajoutée." Tom Gilb ; "On a oublié qu'il s'agissait d'une activité humaine." Hubert Matthews ; "Il y a tant de gens qui ne font pas les choses correctement (euphémisme)." Russel Winder ; "L'académie n'a pas réussi à élever le niveau." Peter Sommerlad ; "C'est comme si on voulait savoir si les gens baisent correctement ? Ce n'est pas une question, il n'y a rien à répondre." James Coplien.

Un sujet important a été la question de l'enregistrement de la profession d'ingénieur logiciel, comme on enregistre les médecins, ou les architectes. Pas grand monde ne soutient cette idée, même si on en parle, ici en Angleterre. Et puis quelle serait la conséquence sur les développements de logiciels libres ?

La question de la qualité des logiciels est revenue à propos des consultants. Ils sont nombreux et finalement trouvent que si le logiciel qu'ils ont vendu fonctionne bien, ils ont tendance à perdre le contrat de support. Et donc, c'est mieux de continuer à faire de mauvais logiciels. Un peu moins mauvais que les concurrents, mais avec plein de bugs dedans.

Ainsi, HM avait demandé à Microsoft quand est-ce qu'ils arrêteraient de faire des logiciels si mauvais ? "Quand vous ne les achèterez plus !" Ou PS qui souhaite des compilateurs qui détectent la compétence du programmeur. Pour le C++, c'est déjà fait : qui comprend les messages d'erreurs des templates ?

Pour finir, l'idée générale est que le logiciel a envahi et détruit de nombreux secteurs industriels (un reboot de lave vaisselle) que nous sommes redevables envers des pans entiers de l'économie. On a tellement bousillé de choses qu'on ne peut que faire mieux. On va continuer à travailler à l'amélioration des logiciels parce que les programmeurs ont envie de bien faire. N'oublions pas que la seconde motivation est le fun. Et on a envie d'avoir du fun en programmant. Alors allons y !