IceScrum : Configurer l’application sur Tomcat avec PostgreSQL

Voici une description de l’installation d’IceScrum avec Tomcat et PostgreSQL sur Windows.

Binaires d’installation

Installation

PostgreSQL

  • Il s’agit d’une installation simplifiée. Plusieurs clics sur suivant devraient permettre d’obtenir une installation standard. Cependant préféré une installation sur C:\Applications plutôt que sur C:\Program Files qui pourrait poser des problèmes de droits d’installation avec Windows.
  • Créer la BDD icescrum

Tomcat

  • Décompresser Tomcat dans un dossier, classiquement sur C:\Applications. L’exécution de bin\startup.bat devrait permettre d’obtenir l’accès à l’interface Web Tomcat sur http://localhost:8080.
  • Pour avoir un accès sur le déploiement des applications, il faudra créer un utilisateur avec le rôle manager-gui. Modifier le fichier conf/tomcat-users.xml avec les lignes suivantes :
<role rolename="manager-gui"/>
<user username="tomcat" password="tomcat" roles="manager-gui"/>
  • Eteindre Tomcat

Driver JDBC

  • Copier le fichier jar dans le dossier lib de Tomcat et supprimer le fichier lib/tomcat-jdbc.jar

IceScrum

  • Décompresser le fichier war (qui est en fait un zip) et copier le dossier IceScrum dans le dossier webapps de Tomcat.
  • Modifier le fichier bin/catalina.bat avec la ligne suivante (adapter les valeurs des dossiers à celles de votre installation)
set "CATALINA_OPTS=-Dicescrum.log.dir=C:\Applications\Tomcat\apache-tomcat-7.0.34\logs 
-Duser.timezone=UTC -Dicescrum_config_location=C:\Applications\Tomcat\apache-tomcat-7.0.34\conf\config.groovy 
-Xmx1024m -XX:MaxPermSize=512m"
  • Créer un fichier conf/config.groovy dans Tomcat avec des valeurs comme celles-ci :
//Server URL
grails.serverURL = "http://localhost:8080/icescrum"
//Logging (for debug purposes)
icescrum.debug.enable = true
//Working directory
icescrum.baseDir = "C://Applications//Tomcat//apache-tomcat-7.0.34//webapps//icescrum"
//PostgreSQL
dataSource.driverClassName = "org.postgresql.Driver"
//dataSource.dialect="net.sf.hibernate.dialect.PostgreSQLDialect"
dataSource.dialect="org.hibernate.dialect.PostgreSQLDialect"
dataSource.url = "jdbc:postgresql://localhost:5432/icescrum"
dataSource.username = "postgres"
dataSource.password = "postgres"
//Mail server (These exemple values aren't set by default)
grails.mail.host = "smtp.gmail.com"
grails.mail.port = 465
grails.mail.username = "username@gmail.com"
grails.mail.password = "mypassword"
//Project
icescrum.project.import.enable = true
icescrum.project.export.enable = true
icescrum.project.creation.enable = true
icescrum.project.private.enable = true
//Users
icescrum.gravatar.secure = false
icescrum.gravatar.enable = false
icescrum.registration.enable = true
icescrum.login.retrieve.enable = true
//Alerts
icescrum.auto_follow_productowner = true
icescrum.auto_follow_stakeholder = true
icescrum.auto_follow_scrummaster = true
icescrum.alerts.errors.to = "dev@icescrum.org"
icescrum.alerts.subject_prefix = "[icescrum]"
icescrum.alerts.enable = true
icescrum.alerts.default.from = "webmaster@icescrum.org"
//Attachments
icescrum.attachments.enable = true
  •  L’installation est maintenant terminée.

Lancement

  • Démarrer le serveur Tomcat avec la commande bin/startup.bat
  • Allez sur l’interface IceScrum : http://localhost:8080/icescrum
  • Vérifier qu’après être arrivé sur l’interface, les tables de la BDD ont bien été créées.
  • Il est ensuite possible de créer des utilisateurs et des projets.

Dette technique, capacité et volonté de la réduire

J’ai lu dernièrement un article très intéressant parlant de la dette technique d’une application sur le blog de Claude Aubry :

Ces deux liens donnent une définition plutôt claire de la dette technique et des moyens de la reconnaitre.

Je me permets cependant de compléter ces articles, puisque je suis actuellement dans un cas similaire où j’ai pour mission d’améliorer la qualité et la productivité d’un projet qui supporte une dette technique particulièrement importante.

S’il y a dette technique sur un projet, l’équipe projet ne sera pas à même de la reconnaitre, sinon celle-ci n’aurait pas de dette technique (ou alors minime) à moins d’avoir un éclair de génie et de se dire, « Mais nous avons une grosse dette technique !!! ». Sur le projet que j’encadre actuellement, les développeurs n’ont absolument aucune conscience de la mauvaise qualité des développements et considèrent que les difficultés qu’ils rencontrent sont essentiellement dû à l’environnement particulier de développement (du javascript sur un serveur NetSuite). Le code n’est pas formaté, n’a aucune convention de nommage, ne réutilise pas ces composants, et pire les développeurs font du copier-coller de code à outrance, car ils ne veulent pas casser du code existant de peur d’engendrer des bugs en série. Et bien évidemment, ils ne connaissent pas les tests unitaires et d’intégration. Dans ces conditions, comment voulez-vous que cette équipe soit à même de reconnaitre la dette technique de son projet ?

Capacité à voir la dette technique

Pour reconnaitre la dette technique d’un projet, il est nécessaire de faire appel à une personne extérieure au projet. Cette personne peut être de la même entreprise, mais si tous les projets sont fondés sur les mêmes principes (pas de formatage, pas de convention de nommage, pas de réutilisation de code et pas de tests unitaires), alors il est préférable de faire appel à une personne extérieure, nouvellement embauchée ou intervenant extérieur.

Cette personne devra avoir les capacités techniques et fonctionnelles nécessaires à l’acquisition des bases d’un projet mal ficelé (autant dire de très bonnes compétences) et comprendre ce qui a amené les développeurs à se retrouver dans une telle situation. Compétences et/ou connaissances techniques insuffisantes, pression du business pour avancer toujours plus vite sans réfléchir sur ses actes pour réorganiser le projet au fur et à mesure de son accroissement… Cette personne devra également avoir de gros talents de persuasion et de négociation pour que les développeurs eux-mêmes reconnaissent que quelque chose doit être fait. En effet une personne extérieure au projet et plus spécialement extérieure à l’entreprise aura toujours plus de mal à convaincre, surtout si elle doit faire les preuves de ses capacités.

Mais le plus important n’est pas de reconnaitre cette dette technique, de la faire reconnaitre aux développeurs ou de trouver une solution afin de la réduire.

Volonté à réduire la dette technique

En effet, une fois les premiers acteurs du projet acquis, il va vous falloir convaincre les décideurs, c’est à dire le métier, qu’il y a une grosse dette technique (qu’ils n’ont jamais vu d’ailleurs) que celle-ci est pénalisante pour le projet et que réduire cette dette technique va permettre d’accroitre la productivité par 2 voire 3 fois.

Mais surtout il va falloir leur expliquer que pour combler cette dette technique, vous allez devoir pénaliser la production pendant une période plus ou moins courte (3 mois dans mon cas, mais la dette technique est vraiment très importante) afin de mettre en place un process de développement et/ou une architecture digne de ce nom. Et c’est sur ce dernier point que vous allez rencontrer les plus grosses difficultés.

Rien ne garantit en effet que vous aurez les gains de productivité attendus, qui paraissent tout de même extraordinaire. Le business est bien évidemment dans une phase critique et réduire les développements est inimaginable. Alors vous allez expliquer et négocier, mais si le business a réellement besoin de ces développements, vous pouvez être sur que le planning de votre refactoring va s’allonger dans le temps ou être décalé jusqu’à des temps plus sereins (ce qui d’après mon expérience existe rarement).

Bonne chance pour réussir sur ce dernier point.

PS : La décision de mon example sera prise dans les jours prochains, nous verrons ce qu’en aura décidé le business. (Je crains le pire).

Conseils d’architectes à architectes

L’architecture et la gestion de projet informatique ont en commun de prendre tous les blâmes lorsqu’un projet ou une architecture échoue et de partager le succès avec l’ensemble de l’équipe lorsqu’ils réussissent. Si ceci est vrai pour beaucoup de métiers, cette réalité doit bien nous rappeler à quel point nous sommes tributaires d’une équipe et que nous en faisons donc partie.

J’ai eu l’occasion il y a quelques mois de parcourir quelques vérités sur le métier d’architecte dont je me permets de retranscrire quelques pages. Réfléchissez sur ces quelques points.

Lorsque vous travaillez sur une architecture :

Ne placez votre CV dans le top des priorités : Une architecture n’est pas faite pour élargir vos connaissances, vous faire découvrir de nouvelles technologies ou faire des expériences. Il s’agit de répondre à un problème et une demande par une infrastructure et une organisation.

Simplifiez la complexité, limitez la complexité accidentelle : Pensez simple, vérifiez ce qui est fait, prévenez ce qui va être fait pour que ce soit fait simplement.

La communication est reine, la clareté et le Leadership sont ses serviteurs : La communication est le point le plus important d’un projet. Sans communication, vous courez à votre perte. Et restez simple dans votre communication et investissez-vous dans les tâches que vous confiez.

Recherchez la valeur dans ce que vous dessinez : Si ce que vous proposez n’a pas de valeur, alors il ne sert à rien de l’implémenter. Et il est fort probable que ceci sera refusé, mis de côté ou pénalisera votre planning. Oubliez ce qui n’a pas de valeur ou pas assez dans vos architectures.

Restez debout : Lorsque vous présentez votre architecture, restez debout. Ceci montre votre motivation, votre implication dans votre travail. Ceci rend votre message plus efficace. Vous mettez alors toutes les chances de votre côté pour valider votre conception.

Visualisez l’échaffaudage de votre architecture lorsque vous en parlez : Lorsque vous discutez du design de votre architecture, vous devez être à même de discuter de chaque partie, même si vous n’avez pas encore tous les détails en tête et surtout de combler les lacunes qui pourraient apparaitre dans vos premiers dessins.

Vous négociez plus que vous ne réfléchissez : Eh oui, une fois une architecture dessinée, il vous faut la discuter, l’expliquer et surtout la négocier, pour bien faire comprendre les points importants, ceux que l’on peut adapter et le timing de mise en place. Un vrai travail de négociateur.

Quantifiez : Pour votre architecture, il vous faut quantifier la charge, le planning, les impacts, les risques… Un vrai travail de fourmi.

Une ligne de code a plus de valeur que 500 lignes de spécifications : Effectivement, dans la grande majorité des cas, cette ligne de code sera exécutée plusieurs milliers de fois lorsque votre application sera en à être production. Et elle aura valeur de preuve lorsqu’il va s’agir de savoir ce que fait réellement votre programme. Elle a donc intérêt à être juste, bien écrite et compréhensible. Cette ligne est bien plus importante que vos spécifications. Et c’est d’autant plus vrai avec des méthodologies agiles type Scrum.

Il n’y a pas de solution miracle : Il n’est pas possible d’appliquer les mêmes recettes sur deux projets différents. Chaque projet, chaque application a ses spécificités. Le secteur, les technologies, l’équipe, les connaissances. Il vous faut adapter votre architecture.

Il n’est jamais trop tôt pour parler performances : Si les performances ne sont pas la première priorité dans la construction d’une architecture, elles ne doivent pas être mises de côté, puisque tôt au tard, il y aura des questions de performances auxquelles il faudra répondre. Il vous mieux y avoir réfléchi lors des premières phases de design.

L’architecture de l’application détermine les performances de l’application : Lorsque vous contruisez votre architecture, réfléchissez bien aux performances de votre application. En effet, de mauvais choix d’architecture peuvent avoir des impacts forts sur des performances attendues comme des prérequis à l’application.

Il n’y a pas qu’une seule solution à un problème : La solution unique sans autre alternative n’existe pas. N’essayez donc même pas de le faire croire à vos interlocuteurs.

C’est le business qui décide : Pensez bien que tout ce que vous faites est conduit par le business pour le business. C’est lui qu’il faut séduire, c’est lui qu’il faut satisfaire.

La simplicité avant la généricité; L’utilisation avant la réutilisation : Avant de penser générique, pensez d’abord simple et voyez ensuite si vous pouvez appliquer un modèle générique. Avant de penser réutilisation, pensez déjà à utiliser et vous verrez ensuite si vous pouvez réutiliser.

Mettez les mains dans le camboui : Si vous voulez être crédibles auprès de vos développeurs et de vos managers, il va falloir vous investir sur le plan technique. Supportez vos développeurs lorsqu’ils ont un problème, le résoudre vous-même si besoin.

Intégrez en continu : L’ensemble du travail de l’équipe et le votre doivent être intégré en continu. N’imaginez pas pouvoir assembler toutes les pièces en fin de parcours comme si de rien n’était si vous n’avez pas tout testé ensemble au fur et à mesure des développements du projet. Les méthodes XP d’intégration continue fournissent tous les outils dont vous avez besoin et vous assurent une qualité continue et un risque minimum sur votre projet.

La base de données est une forteresse : une fois le schéma de la base de données défini et les premières lignes de code intégrées, comprenez bien que tout changement sur la base de données aura des impacts forts sur le projet. Cette base de données devrait donc être considérée comme inviolable, sauf quelques mineures, au risque d’impacter la qualité de votre projet et surtout votre planning.

Utilisez l’incertain pour vous guider : Lorsque vous discutez de votre conception, réfléchissez toujours à ce que vous ne savez pas ou ne comprenez pas. Ceci doit vous guider pour définir les bases de votre architecture. Ce que vous ne savez pas présente un risque. Il vous incombe donc de savoir pour diminuer ce risque. Si vous vous apercevez durant votre projet qu’il y a quelque chose que vous ne connaissez pas, vous avez pour tâche de le découvrir afin de limiter ou d’annuler le risque que cette non-connaissance a sur votre projet.

Une vue trop long terme est l’ennemi du succès : Lorsque vous travaillez sur votre architecture, ne pensez pas trop au long terme, ceci pourrait avoir un impact négatif sur le succès de votre projet. Vous empêchant de voir les besoins immédiats et de choisir ce qui est bon.

La réutilisation est une question de personne et d’éducation, pas d’architecture : Il ne suffit pas d’avoir une architecture qui permet la réutilisation de composants, encore faut-il avoir les bonnes personnes avec les bonnes connaissances pour permettre cette réutilisation. Et il faut expliquer la réutilisation pour qu’elle soit effective.

Il n’y a pas de « Je » en architecture : Vous ne pouvez pas vous permettre de dire « je » en tant qu’architecte. Car si certes vous dessinez l’architecture, c’est avec l’aide de beaucoup de collègues de votre entourage, avec des négociations et surtout ce sont les développeurs qui vont l’implémenter.

Prenez du recul : Il est bon de prendre du recul lorsqu’on travaille sur une architecture. Ne pas toujours être « dedans ». Mais attention, il faut savoir ajuster ce recul. Prendre la vue des développeurs, des utilisateurs, managers, sur du court, moyen et long terme.

Essayez avant de choisir : Les choix d’architecture ou de technologie ne doivent jamais être fait sans en avoir fait des essais de ceux-ci. Les risques encourus sont beaucoup trop importants. Et plus les choix sont importants, plus les essais doivent être faits avec soin.

Comprendre le métier : Un architecte se doit de comprendre le métier s’il veut faire une architecture réussie. Et plus l’architecture est importante et plus la connaissance du métier doit être approfondie. Ne négligez jamais cette étape.

Le temps change tout : Dans un projet tout est une question de timing. Il faut laisser le temps au temps et savoir lorsqu’il est temps d’intervenir. Laisser le temps aux managers d’assimiler vos choix et ses impacts, laisser aux développeurs le temps d’intégrer vos concepts et leurs avantages… Et ce qui était vrai hier, n’est pas forcément vrai aujourd’hui et ce qui est vrai aujourd’hui ne le sera pas forcément demain.

Donnez de l’autonomie aux développeurs : Avec l’expérience l’architecte sait que son architecture ne peut être parfaite et qu’elle est sujette à modifications. Celui qui ne l’accepte pas et se veut rigide avec ses développeurs court à sa perte. Ceux-ci n’accepteront pas l’architecture ou l’architecte ou les deux, et soit le projet, soit l’architecture, soit les deux vont échouer. Laisser les développeurs proposer des solutions, discuter avec eux de ce qu’il est envisageable de faire lorsqu’ils se retrouvent confronter à des problèmes que votre architecture ne peut résoudre d’elle-même et adapter.

Le contexte est Roi : Des règles d’architecture qui s’appliquent dans un contexte ne s’appliqueront pas dans un autre. Tout est fonction du contexte. Vous ne pouvez pas créer une architecture ultra-performante et complexe si vous n’avez de développeurs aptes pour la comprendre par exemple. Prenez en compte le contexte lorsque vous dessinez votre architecture.

Accompagnez vos développeurs

Depuis quelques temps, je lis beaucoup de documentations sur la gestion de projet avec Scrum, le Lean Development, l’eXtreme Programming et l’agilité. Je suis toujours ravi de voir qu’une des bases de ces concepts est de fournir un produit avec une structure technique de qualité. Qualité de l’architecture, qualité de la documentation, qualité du code.

Mais chaque fois que j’arrive dans une nouvelle entreprise, je suis toujours étonné de la qualité de ce qui a été conçu.

  • On parle d’architecture, mais il n’y a pas d’architecte.
  • On parle de documentation, mais il n’y a pas de document.
  • On parle de logiciels, mais lorsqu’on étudie le code, on voit clairement le concept principal, « je code vite, je code pour que çà marche, le reste (bon code, commentaires, syntaxe généralisée) on verra plus tard (c’est à dire : jamais)« .

Je crois avoir presque tout vu :

  • Des classes avec le nom du développeur, très pratique quand il ne fait que passer sur le projet,
  • Du code très très technique qui marche à moitié, mais dont on ne sait pas grand chose car il n’y a aucun commentaire, aucune doc et puisque le développeur est parti depuis de nombreuses années,
  • Du code de base, mais sans aucun commentaire, aucune règle, aucune organisation,
  • Des méthodes très longues (+ de 2000 lignes),
  • Du code avec plus de codes commentés que de codes exécutés,
  • Des classes avec des méthodes sans paramètres, les membres de classe sont utilisés comme paramètres, imaginez l’enchevêtrement lorsque le code n’est pas exécuté dans le bon sens,
  • Des membres de classes définis par le constructeur mais jamais utilisés, pratique lorsqu’on se dit que la classe pourrait répondre à nos attentes avec un paramètre mais qu’il n’en est rien,
  • Des projets où tous les fichiers (pages web, classes, javascript, images, fichier de properties…) sont à la racine du projet, aucun dossier, super pour rechercher ses fichiers,
  • Des classes avec l’ensemble de toutes les valeurs utilisées éparpillées dans le code, en dur, répétées des dizaines de fois. Vous changez le nom d’une valeur, il faut le changer dans 10 classes différentes, imaginez lorsque vous travaillez sur un fichier xml et que l’ensemble des balises est répété à plusieurs endroits, comprendre le code, le modifier ou le réutiliser sont un vrai bonheur,
  • Des logs en dur avec System.out partout, avec marquez « toto3, « test1 » ou « passe par ici », « passe par là »,
  • Des centaines de lignes de code copier-coller, avec une ou deux lignes qui changent, comme ça, pour corriger les bugs, ce sera le bonheur,
  • Des développeurs qui, pour adapter leur projet à un process particulier, préfèrent créer une nouvelle branche et faire les quelques modifications qui s’imposent, plutôt que de faire fonctionner leur esprit afin d’ajouter un paramètre dans une méthode,

Ce ne sont que quelques extraits, et ils ne sont pas réservés à des développeurs junior, bien au contraire.

La seule société où j’ai pu travailler sur un code de qualité remonte à ma première expérience en Suisse. Certes les Suisses sont connus pour la qualité de leur travail, mais on peut dire qu’ici le code (et le développeur) était traité avec le respect qui lui est du. Règles de développement, commentaires, documentations, process strict, packages, rôles… Débuter dans cette société m’a permis d’intégrer un point essentiel que tout développeur devrait maitriser. Le développement de qualité.

Et lorsque vous croisez un ‘mauvais’ développeur (mauvais dans le sens où il ne respecte pas de standard en développement, commentaires, organisation), vous ne pouvez pas le blâmer. S’il n’a pas été éduqué pour faire du bon code, il faudrait qu’il prenne sur lui afin d’apprendre seul, ce qui n’est jamais facile.

Qui blâmer alors si on ne peut pas blâmer le développeur ?

Facile, son supérieur direct. Le chef d’équipe ou le chef du projet. On entend souvent qu’un chef d’équipe ou un chef de projet informatique n’a pas besoin de connaitre l’informatique pour être un bon chef. Faites moi rire, vous en connaissez beaucoup des chefs IT qui n’ont jamais fait de développements ? Je n’en ai jamais croisé.

Son rôle est certes de gérer l’équipe ou le projet mais il est également de s’assurer de la qualité de ce qui est produit et pas seulement que le produit répond aux attentes ou non. Ce serait un peu trop facile.

Alors oui, c’est long, oui, c’est fastidieux, oui, il faut répéter, insister, vérifier, re-vérifier. Mais si vous voulez des développeurs de qualité, il vous faut fournir un travail de qualité. Si vous ne faites pas ce travail avec vos développeurs en controlant, expliquant pourquoi vous voulez ceci comme ca, et pas autrement, vos développeurs ne seront jamais de bons développeurs et vous aurez des difficultés par la suite à faire avancer votre projet. Prenez le temps maintenant, vous en gagnerez beaucoup plus tard.

Accompagnez vos développeurs !!!

De l’utilité des architectes SI.

On a vu passer assez récemment des articles sur la blogosphère dénigrant le métier de l’architecte. je parle ici de l’architecte des SIs, par de celui des maisons, même si le lien entre les 2 métiers est proche.

A-t-on réellement besoin d’un architecte SI lorsque l’on développe un nouveau logiciel. Vous me direz « ça dépend ». Je vous répond « ça dépasse » (les fans comprendront 😉 ). Plus sérieusement, je vous répondrais « Toujours ».

En effet, vous avez plus à gagner à utiliser les services d’un architecte plutôt que de ne pas les utiliser, tant en terme de coût, qu’en terme de délai. Pour plagier une pub qui passe en ce moment à la radio, « Pourquoi se dit-on toujours APRES qu’il aurait fallu les conseils d’un architecte AVANT? »

Pourquoi se dit-on toujours après qu\'il aurait fallu s\'en occuper avant?

Agir avant, c\'est prévoir, réagir après, c\'est subir.

Ce qui est vrai pour les notaires, l’est également pour les architectes comme pour les experts. Certes utiliser les services d’un architecte ou d’un expert peut coûter cher, en temps comme en délai, mais il peut vous faire économiser beaucoup pour la suite.

Si je prends l’exemple des 2 projets sur lesquels je travaille en ce moment, les deux projets auraient nécessité les compétences d’un architecte ou d’un expert. Pourquoi ceci n’a pas été fait, pour le premier parce que le besoin d’un architecte (ou d’un expert) ne s’est pas fait sentir immédiatement, même s’il est venu plus tard et que l’intervention s’est faite (mal) avec précipitation. Pour le second, parce qu’on a supposé que le travail d’architecture avait été fait, alors qu’il s’agissait en fait d’un travail d’urbanisation (ne pas confondre les deux) et que le besoin s’en ressent fortement maintenant (mauvaise performance, mauvais choix d’implémentation…).

Bref dans les 2 cas, vous l’aurez compris, pas d’intervention d’architecture, un avancement à l’aveugle, et des retards en cumul (même si la non-intervention de l’architecte n’est pas la cause de tous les retards).

Prenons l’image de l’architecte de batiment, certes celui-ci est obligatoire par la loi pour une construction. Mais imagineriez-vous ne pas utiliser les services de cet architecte pour construire votre maison. Et les normes à respecter, et les avantages de telles solutions plutôt que telles autres, et les emplacements des portes, fenêtres, toits… Un couvreur peut très bien faire un toit (et heureusement me direz-vous), mais celui qui est le mieux à même de savoir comment doit être fait le toit, où et avec quels procédés, c’est l’architecte. Et bien il en est de même entre le développeur et l’architecte SI. Qui est le mieux à même de savoir comment développer telle fonctionnalité, de faire telle liaison de composants entre 2 modules, c’est l’architecte, pas le développeur.

Alors chers collègues, que vos décideurs, que vos plannings, que vos « meilleurs conseillers » vous expliquent mille fois qu’un architecte n’est pas utile pour votre projet, parce que ceci, parce que cela… N’en croyez rien. Utilisez les conseils d’un architecte, vos décideurs, vos plannings, vos « meilleurs conseillers » vous en seront reconnaissants, pas le jour de son intervention (quoique) , mais très surement le lendemain.

%d blogueurs aiment cette page :