Liste de partage de Grorico
Xavier de la Porte, producteur et animateur de l’émission Place de la Toile sur France Culture, effectue chaque semaine une lecture d’article dans le cadre de son émission. Cet article a été publié le 6 avril sur InternetActu.
La lecture de la semaine, encore une fois, sera une chronique de Clive Thompson dans le dernier numéro du magazine américain Wired, car, encore une fois, cette chronique est tout à fait passionnante. Son titre n’est pas ce qu’elle a de mieux, mais il est suffisamment intriguant pour donner envie de poursuivre : “Avantage aux Cyborgs : pourquoi l’accès à une intelligence supérieure passe par l’amélioration des relations avec vos assistants numériques.” Je vous rassure, la suite est plus claire.
Clive Thompson commence par poser une question obsédante et désormais classique:
Qui, de l’homme ou de la machine, est le plus intelligent?
En 1997, rappelle Thompson, Deep Blue, le superordinateur d’IBM, a fait nettement pencher la balance en faveur des robots en battant Garry Kasparov aux échecs. Deep Blue a gagné parce que les ordinateurs peuvent produire, à la vitesse de la lumière, des calculs presque infinis : ce dont les humains sont incapables. Ce fut le prima de la force brute, de la capacité à passer en revue des millions de mouvements possibles pour trouver les meilleurs. Ce n’est pas comme ça que les humains jouent aux échecs. Les Grands Maîtres, nous rappelle encore Thompson, s’appuient, pour choisir le bon mouvement, sur des stratégies et des intuitions fournies par des années d’expérience et d’étude. Les intelligences humaines et artificielles ne travaillent pas de la même manière, ce qui a donné à Kasparov une idée intrigante.
C’est là où le papier de Thompson commence à nous apprendre quelque chose (en tout cas à m’apprendre quelque chose). Quelle fut l’idée de Kasparov ? Et si, au lieu de faire s’affronter les humains et les machines, on les faisait travailler en équipe ? Kasparov a donc créé ce qu’il a appelé les advanced chess, les “échecs avancés”, dans lesquels les joueurs sont assistés par un logiciel. Chaque compétiteur entre la position de ses pièces dans l’ordinateur et utilise les mouvements proposés par le programme pour faire ses choix.
La revanche des esprits moyens
En 2005, dans un tournoi en ligne où tout le monde pouvait concourir, certaines paires humain-machine étaient tout à fait étonnantes. Mais celle qui remporta le tournoi ne comptait aucun Grand Maître, ni aucun des superordinateurs présents dans la compétition. Ce fut une équipe d’amateurs d’une vingtaine d’années, assistés par des PC ordinaires et des applications bon marché qui l’emporta. De quoi ont-ils tiré leur supériorité ? La réponse apportée par Thompson commence à nous éclairer sur le sens de son titre. Leur supériorité est venue de leur aptitude à tirer le meilleur parti de l’aide que leur apportait l’ordinateur. Ils savaient mieux que les autres entrer leurs mouvements dans la machine, ils savaient quand il fallait consulter le logiciel et quand il valait mieux ne pas suivre ses conseils. Comme Kasparov l’a dit ensuite, un être humain faible avec une machine peut se révéler meilleur qu’un être humain fort avec une machine si l’être humain faible a une meilleure méthode. En d’autres termes, selon Thompson, les entités les plus brillantes de notre planète ne sont ni les êtres humains les plus accomplis ni les machines les plus accomplies. Ce sont des gens à l’intelligence moyenne qui ont une aptitude particulière à mêler leur intelligence à celle de la machine.
Le grand-maître Ponomariov en 2005 face à la machine
Et pour Thompson, cela ressemble beaucoup à ce qui se passe dans nos vies. Aujourd’hui, nous sommes continuellement engagés dans des activités “cyborguiennes”. On utilise Google pour trouver une information, on va sur Twitter ou Facebook pour se tenir au courant de ce qui arrive aux gens qui nous intéressent, et d’autres choses encore.
Or, un grand débat oppose ceux qui adorent notre vie moderne et numérique à ceux qu’elle perturbe. D’après Thompson, l’exemple fourni par les échecs nous montre pourquoi il existe un tel fossé. Ceux qui sont excités par les technologies sont ceux qui ont optimisé leurs méthodes, ceux qui savent comment et quand on s’appuie sur l’intelligence de la machine. Ceux qui ont adapté leur profil Facebook, configuré leurs fils RSS, etc. Et même, plus important, ceux qui savent aussi quand il faut s’écarter de l’écran et ignorer le chant des distractions qui nous appellent en ligne. Le résultat, c’est qu’ils se sentent plus intelligents et plus concentrés. A l’inverse, ceux qui se sentent intimidés par la vie en ligne n’atteignent pas cet état délicieux. Ils ont l’impression qu’internet les trouble, qu’il les rend “bêtes” pour reprendre le mot de Nicholas Carr.
Or, et on ne peut que donner raison à Clive Thompson, on ne peut pas faire comme si l’âge des machines étaient en passe de s’achever. Il est certain que l’on va de plus en plus dépendre de l’assistance numérique pour penser et se socialiser. Et trouver le moyen d’intégrer l’intelligence de la machine à nos vies personnelles est le défi le plus important qui nous soit offert. Quand s’en remettre à la machine ? Quand se fier à soi-même ? Il n’y a pas, d’après Thompson, de réponse univoque, et il n’y en aura jamais. Il s’agit là, selon lui, d’une quête personnelle. Mais en aucun cas nous ne devons éluder la question tant les avantages cognitifs sont grands pour ceux qui savent le mieux penser avec la machine. Au final, dit Thompson, la vraie question est : “quelle sorte de cyborg voulez-vous être ?”
Cette chronique de Thompson est passionnante pour elle-même, mais elle l’est aussi, me semble-t-il, pour ce qu’elle ouvre comme pistes. Et notamment, pour une explication qu’elle peut apporter à la crainte d’une partie des élites, et des élites françaises en particulier, face à l’internet. Car si Thompson, à la suite de Kasparov, a raison, si une intelligence moyenne alliée à une bonne maîtrise de la machine renverse les hiérarchies au point de se révéler supérieure à des années de travail et d’accumulation de savoir ; si cette règle s’avère exacte dans d’autres disciplines que dans les échecs, alors quelle supériorité resterait à ceux qui savent, ceux que l’on considère comme très intelligents, mais qui vivent sans les machines, qui les craignent, les méprisent, et ne s’en servent pas ? Et s’il y avait, derrière les arguments des contempteurs d’internet, la manifestation de cette crainte, la crainte d’un monde dans lequel ils ne domineraient plus, d’un monde qui menacerait leur position. Ça n’est qu’une hypothèse, mais il faut avouer qu’elle est tentante.
Article initialement publié sur InternetActu
A la lecture des appels d’offres publics pour la réalisation d’applications logicielles, on assiste ces derniers temps à une percée des méthodes agiles, dont l’utilisation désormais est exigée dans les réponses des candidats ; l’Agile semble donc enfin unanimement reconnu comme un outil d’amélioration, à la fois du processus de construction des applications, et de la satisfaction des acteurs, qu’il s’agisse des utilisateurs finaux, ou des artisans du système d’information.
Pour autant, la mise en œuvre de l’Agile dans des organisations traditionnelles ne va pas de soi. Le premier problème auquel on se heurte, avant même de commencer le projet, concerne la contractualisation. Ce problème de contractualisation a déjà été abordé sur ce blog. Nous proposons, dans ce billet, de nous concentrer sur un point précis : le Plan Assurance Qualité (PAQ), pièce contractuelle inévitable dans le cadre traditionnel des marchés…
Profitons donc de nos retours d’expérience _ nous avons été récemment amenés à rédiger des PAQ dans un cadre agile, et montrons comment valoriser la qualité dans un projet agile à travers l’exercice du PAQ. Le débutant en agilité trouvera dans ce billet un condensé des pratiques de qualité liées à l’Agile, tandis que l’initié pourra trouver de l’aide pour la rédaction d’un PAQ.
Agile et PAQ : un exercice contre nature ?
A priori, parler de PAQ en Agile peut sembler incongru. En effet, la documentation formelle n’est pas plébiscitée par l’Agile qui préfère le concret, le tangible, à la prose. Par exemple, en Agile, on ne rédige pas de dossiers de spécifications mais on parle de user stories qui sont décrites sous forme de cas de tests. De même, pour la réalisation de la qualité, on préfère dire qu’elle est portée intrinsèquement par la méthodologie plutôt que d’en expliciter les principes dans un document. A fortiori si ledit document doit être rédigé en amont du projet : « stocker » ainsi, en avance de phase, de l’information qui sera amenée à évoluer au cours du projet peut paraître contre-productif. On notera également que l’agile manifesto n’emploie absolument pas le mot qualité… Au-delà de l’anecdote, comment faire quand il s’agit de répondre à un appel d’offres pour lequel la fourniture d’un PAQ quasi finalisé est un élément essentiel de la réponse ?
Rappelons qu’un PAQ, défini selon la norme AFNOR/Z67-100-3, est un « document qui précise les éléments permettant de s’assurer de la mise en œuvre et de l’efficacité des activités prévues pour obtenir la qualité requise ». Il s’agit donc d’expliquer comment l’Agile permet de réaliser la qualité, mais aussi comment on mesure que cette qualité est effectivement réalisée.
Faisons l’exercice.
Avant tout, qu’entend-on par qualité dans le cas d’une application logicielle ? Il nous semble qu’une application de qualité répond aux exigences suivantes :
- L’application répond au besoin fonctionnel et permet aux utilisateurs de travailler efficacement
- Il y a peu, voire pas, d’anomalies
- L’application est livrée dans les délais impartis
Comment l’Agile permet-il de répondre à ces exigences ? Examinons chaque point.
L’application répond au besoin fonctionnel et permet aux utilisateurs de travailler efficacement.
En Agile, le besoin fonctionnel est traduit en user stories, elles-mêmes décrites sous forme de tests de recette fonctionnelle. Le simple fait de décrire le test de recette fonctionnelle, tout en fournissant les jeux de données de test, garantit que les développeurs seront en phase avec les attendus. Et si d’aventure, un doute subsiste sur le besoin, la proximité des acteurs prônée par l’Agile permet de le lever sans délai. En effet, équipe fonctionnelle et équipe technique forment une seule et même équipe, qui travaille sur le même plateau projet ; la communication s’en trouve donc largement favorisée. Enfin, l’équipe fonctionnelle recettant au fil de l’eau, les anomalies fonctionnelles sont détectées au plus tôt.
Encore faut-il que les attendus définis par l’équipe fonctionnelle correspondent aux attendus des utilisateurs de l’application. Or, non seulement l’Agile préconise d’associer les utilisateurs finaux au cours d’ateliers de conception fonctionnelle, mais surtout, le développement itératif et incrémental permet de livrer à intervalles réguliers une version fonctionnelle de l’application, qui peut être utilisée pour recueillir le feed-back du métier.
L’Agile met donc en œuvre des pratiques permettant de garantir la conformité de l’application aux attendus fonctionnels.
Il y a peu, voire pas, d’anomalies
L’Agile prône de respecter des bonnes pratiques de développement permettant de garantir la qualité du code. Parmi ces pratiques, citons le développement par les tests (TDD _ test driven development), la revue de code, les ateliers collaboratifs de design de l’application et le développement en binôme (pair programming). L’utilisation de TDD permet la construction conjointe du programme et d’un « harnais de tests » de non régression. La revue de code permet d’identifier des bugs avant de les rencontrer au moyen d’une relecture du code par un développeur expérimenté ; elle permet également de garantir l’homogénéité du code, et ainsi, son évolutivité ou sa réversibilité. Les ateliers collaboratifs de design de l’application et le développement en binôme permettent de challenger les choix techniques effectués et donc d’améliorer de manière continue la qualité technique.
En parallèle de ces pratiques, le recours à un outillage de l’environnement de développement via des usines logicielles permet de centraliser le code, d’automatiser le build, d’automatiser les tests unitaires. On réduit ainsi le risque d’introduire des erreurs dans le code tout en libérant les développeurs de tâches récurrentes sans valeur ajoutée. Enfin, les outils de reporting logiciel permettent d’analyser de manière automatique la qualité du code.
L’Agile met donc en œuvre des pratiques de développement et un outillage de l’environnement de développement qui optimisent la réalisation de la qualité logicielle.
L’application est livrée à temps
L’Agile prône le pilotage par la valeur : le backlog, c’est-à-dire la liste des user stories à développer, est priorisé en fonction de ce qui a le plus de valeur pour le métier. Le respect des délais de TTM (Time-to-Market) est garanti, grâce à ce mécanisme de priorisation : si un jalon est fixé, la priorisation du backlog assure de pouvoir délivrer pour le jalon une version cohérente du logiciel.
De plus, le développement par itérations courtes permet de garder une visibilité permanente sur le réalisé et le reste à faire. Le reste à faire et la date d’atterrissage sont prédictibles, d’autant plus que l’équipe de développement apprend en quelques itérations à estimer de manière très fiable la complexité des user stories à développer.
L’Agile repose donc sur un mode de pilotage qui garantit de livrer une application fonctionnelle en temps et en heure.
Nous voyons donc qu’il est aisé de décrire les mécanismes permettant d’assurer la qualité en Agile.
Bouclons l’exercice.
Pour boucler l’exercice, il nous reste à montrer que l’Agile rend mesurable la qualité. En somme, quels KPIs pouvons-nous tirer de la méthodologie ?
L’indicateur phare de l’Agile est la vélocité. Calculée à la fin de chaque itération, la vélocité représente le nombre de points de complexité développés pendant l’itération ; sa valeur moyenne et la tendance permettent d’estimer le délai nécessaire à la réalisation du reste à faire. Il s’agit donc de l’indicateur qui va permettre de s’assurer que l’application est livrée à temps.
A côté de la vélocité, les spécifications par les tests permettent intrinsèquement de mesurer la conformité de l’application au besoin : le nombre de tests de recette qui passent est connu au fur et à mesure que la recette s’effectue.
Enfin, l’outillage de l’environnement de développement, et en particulier l’utilisation d’un outil de reporting logiciel, permet de remonter les KPIs de qualité logicielle, qu’il s’agisse du taux de couverture de tests unitaires, de la complexité cyclomatique, de la cohérence des classes ou encore du respect des règles de qualité du code.
Nous voyons donc que l’Agile porte intrinsèquement ou permet d’extraire facilement les KPIs nécessaires à la mesure de la qualité.
En conclusion
Nous avons donc pu voir que l’exercice du PAQ n’est pas si terrible avec les méthodes agiles : il est aisé de trouver de la matière ! Si l’Agile ne revendique pas haut et fort la qualité et la rigueur permettant de l’atteindre, ces dernières sont bien portées en filigrane dans ses valeurs fondatrices. Et si l’exercice peut paraître rébarbatif, il a le mérite de poser sur le papier les vertus de l’Agile, ce qui lui confie un rôle didactique et pédagogique.
Suggestion d'articles :
La fondation OpenStreetMap a lancé depuis le 1er décembre 2011 une campagne de financement. Elle est destinée principalement à l'acquisition d'un serveur de sauvegarde supplémentaire. L'objectif est de récolter 15 000 £, soit un peu moins de 18 000 €.
Pour les néophytes, OpenStreetMap est un projet collaboratif qui a pour objectif de créer une base de données spatiale du monde sous licence libre, en utilisant les systèmes de positionnement satellite ainsi que d'autres données libres. Ces données peuvent être utilisées pour produire des cartes, faire des analyses et des statistiques de territoire, etc. C'est en quelque sorte le Wikipédia de l'information géographique.
- lien n°1 : Pour donner !
- lien n°2 : L'annonce de la campagne de financement
- lien n°3 : Des détails sur le serveur à financer
- lien n°4 : Informations sur la campagne de 2009
- lien n°5 : Pour payer avec autre chose que Paypal
- lien n°6 : Consulter la carte d'OpenStreetMap
Contrairement à ce qu'il s'est passé lors de la campagne de financement (en 2009), les caisses se remplissent plus lentement. À l'époque, les 10 000 £ avaient été atteints en moins de 3 jours. Ce n'est pas le cas en 2011, d'où l'objet de cette dépêche. En plus, la période des fêtes se prête allègrement à cet exercice de dons...
Chose intéressante, à l'inverse d'autres fondations (dont Wikimédia), cette somme d'argent est mise en priorité sur du matériel qui servira directement l'infrastructure technique du projet et pourra fortement améliorer le service rendu aux utilisateurs et aux contributeurs d'OpenStreetMap. Votre contribution ira donc directement dans du matériel et ne sera pas emmagasinée sur le compte en banque de la fondation ou utilisée pour d'autres postes de dépenses plus indirects tel que le financement des plans de communication ou les billets d'avion des intervenants (même si ces postes sont très utiles pour faire avancer le projet).
De plus, la fondation OpenStreetMap est propriétaire de son matériel ce qui lui assure une plus grande indépendance par rapport à un prestataire qui déciderait de changer subitement les règles ou qui ferait faillite.
Voilà donc une opportunité (en or en €) à saisir pour contribuer directement au projet. Si ça fait longtemps que vous n'avez pas déposé de données dans OpenStreetMap, vous avez une chance supplémentaire de vous rattraper !
En ce qui concerne les dons, ceux-ci peuvent se faire par PayPal, en livres Sterling ou en Euros. Les personnes qui souhaitent éviter cet opérateur de transfert d'argent peuvent toujours effectuer un virement (même si c'est plus cher mais quand on a des principes, on ne compte pas ;-)) selon les modalités indiquées par la fondation.
Souhaitons, avec un peu d'avance, un joyeux Noël à ce projet libre de référence !
Ca n'a l'air de rien, et pourtant, faire une recherche sur Google portant ses fruits peut être compliqué. Une récente étude montrait même que seuls 25% des étudiants de l'Université de l'Illinois aux Etats-Unis étaient capables de construire une requête "raisonnablement bien exécutée". Dommage pour les 75% restants... Cette infographie reprend donc quelques conseils bien utiles pour trouver plus facilement ce que l'on souhaite sur Internet : elle est destinée principalement aux étudiants effectuant des travaux de recherche, mais chacun y tirera des bénéfices ! Par exemple, poser une question à Google est inutile (et pourtant, on en rencontre assez souvent), il faut plutôt cibler les mots clés en fonction de ce que l'on souhaite trouver. L'infographie donne également les commandes de Google qui devraient vous simplifier la vie, si vous ne les connaissiez pas. Ecrire sa requête entre guillemets permettra de faire la recherche sur cette expression exacte ; taper le signe - avant exclura ces mots (utile pour chercher des renseignements sur la tomate, en excluant les recettes de cuisine par exemple), fouiller dans un site Internet particulier sera possible en tapant site:nomdusite avant sa recherche... Toutes sortes d'astuces que nous n'exploitons pas forcément suffisamment. Vous pouvez également vous reporter à la liste de conseils établie par Google, ainsi qu'aux outils destinés à simplifier la recherche.
Source : Mashable, infographie réalisée par HackCollege
