De geek à directeur technique

Le blog d'un geek devenu directeur technique

Accueil Présentation Votre carrière Organisat° perso. Organisat° d'équipe Créat° d'entreprise Outils Technique Skriv

Aller au contenu | Aller au menu | Aller à la recherche

jeudi 4 février 2010

Skriv : Fonctionnalités

Par Amaury le jeudi 4 février 2010, 20:50 - Skriv

(ce billet fait partie d'un ensemble consacré au projet Skriv)

Alors, j'ai commencé par discuter de l'accès au service et de son prix. Maintenant il serait bon de s'attacher au cœur du problème : à quoi va-t-il servir exactement, quelles vont être ses fonctionnalités ?

Je voudrais définir un outil qui puisse servir aussi bien pour gérer des projets professionnels que personnels. Je dois avouer que la plupart de mes projets personnels ressemblent furieusement à des projets informatiques, mais ce n'est pas une règle absolue.
Comme je l'ai dit en commentaire du précédent billet, la vision que j'ai de Skriv est celle d'un outil de travail collaboratif plus que d'un outil de gestion de projet. Je ne souhaite pas faire un logiciel qui servira uniquement aux “décideurs” pour suivre le travail de leurs employés ; je veux faire le méga-tableau-de-bord qui servira tous les jours (et plusieurs fois par jour !) à l'ensemble de mes collaborateurs pour organiser leur travail, pour communiquer sur tous les aspects de leur travail.

Fonctions de base

On peut reprendre les 4 grands types de fonctionnalités habituelles :

  • Un affichage “tableau de bord” qui affiche l'activité récente sur un projet ou sur tous les projets auxquels l'utilisateur a accès.
  • Les listes. Il faut pouvoir créer autant de listes que nécessaires, avec la possibilité de les adapter aux besoins (buglist, todolist, checklist).
  • Les pages de documentation textuelle. Appelons ça un "wiki", même si j'hésite entre l'utilisation d'une syntaxe de type wiki et l'utilisation d'un éditeur HTML WYSIWYG. Il faut pouvoir lier une page de wiki à une tâche.
  • Le partage de fichiers. Chaque projet a bien souvent besoin de fichiers binaires, qu'il s'agisse de feuilles de calcul, d'images ou autres. Il faut pouvoir lier un fichier à une tâche.

Fonctions supplémentaires

Ce qu'on peut y ajouter :

  • Des “vues” calendaires, mais je place ça plutôt dans la partie ergonomie/affichage. Cela reste important, surtout si on se sert de ces vues pour éditer les tâches (ce qui revient plus ou moins à avoir un diagramme de Gantt).
  • Des rappels par email ou SMS, que ce soit pour nous rappeler des tâches (todolist/buglist de projet) ou définis personnellement.
  • La connexion à un compte IMAP. Il y a toujours des informations importantes qui sont échangées par email (même si ce n'est pas une bonne pratique). On pourrait dédier un dossier IMAP à chaque projet, et y accéder via l'interface. On pourrait trouver un moyen pour créer des tâches à partir d'emails, et extraire les pièce-jointes des emails pour les ajouter au partage de fichiers.
  • Un système de micro-blogging. Même si j'ai déjà fait part de mon scepticisme vis-à-vis de ce genre d'outil, il y a sûrement moyen de créer un canal de communication supplémentaire. Les micro-messages seraient affichés sur le “tableau de bord” au milieu des indications d'évolution du projet.

Concernant la «communication» :

  • On pourrait imaginer que le logiciel pourrait envoyer des emails avec un résumé quotidien ou hebdomadaire des évolutions d'un ou plusieurs projets qu'on aurait décidé de "suivre".
  • Il faudrait proposer des flux RSS permettant aux utilisateurs de suivre leurs projets dans un outil externe. Un flux qui reprenne l'activité de tous les projets, un flux pour l'activité des projets “suivis”, et un flux par projet.
  • Il faudrait aussi proposer un export au format ICS (iCalendar), pour permettre de suivre les tâches et les projets dans un outil externe comme iCal, Sunbird ou Google Calendar.

Fonctions à intégrer ?

J'hésite encore sur certaines fonctionnalités :

  • Gestion des compte-rendus d'activité. Je sais que c'est vraiment nécessaire pour certaines entreprises, celles qui factures leurs clients en fonction du temps passé sur les projets. Et, de manière générale, il est toujours bon de savoir combien aura coûté un projet. Mais j'ai un peur peur de complexifier l'ensemble du logiciel pour une fonctionnalité qui n'est pas utile à tout le monde.
  • Un forum de discussion propre à un projet peut parfois être très utile, surtout pour les équipes qui sont éclatées géographiquement. Mais je me dis que si le système de micro-blogging est bien fait, et qu'il autorise les vrais fils de discussion, il n'y aura pas besoin de faire un forum séparé du reste.
  • Une édition collaborative simultanée en temps réel des pages de wiki. Un outil comme EtherPad permet de travailler à plusieurs sur le même document, en même temps. Mais c'est quand même un niveau de complexité bien supérieur, pour un usage qui reste encore à démontrer, je pense.
  • Permettre de créer des dessins directement dans l'interface, par exemple en utilisant un outil comme FlockDraw. Un dessins vaut souvent mieux qu'un long discours. Alors c'est souvent intéressant d'ajouter des diagrammes explicatifs dans les fichiers d'un projet. Habituellement, il faut utiliser un logiciel de dessin, enregistrer l'image puis l'uploader sur le projet. Si on pouvait directement dessiner ”online”, ce serait plus pratique, non ?

Fonctions à ne pas intégrer

Ce que Skriv ne sera jamais :

  • Un carnet d'adresse.
  • Un calendrier complet pour gérer ses rendez-vous.
  • Un CRM.
  • Un outil de gestion de code source, d'édition de code, de profiling, de déploiement à distance, ...
  • Un serveur d'intégration continue.
  • Un outil de facturation ou un ERP.

Avez-vous des idées de fonctionnalités qui vous semblent nécessaires, en plus de celles-ci ?

aucun commentaire aucun rétrolien

dimanche 31 janvier 2010

Les clés de la réussite

Par Amaury le dimanche 31 janvier 2010, 18:35 - Votre carrière

Je n'aime pas le titre de cet article, il est assez pompeux et ressemble à une "formule miracle". Mais je n'en ai pas trouvé de meilleur.

Je me suis déjà retrouvé plusieurs fois à tenter d'expliquer à de jeunes informaticiens (hum, même à des moins jeunes, d'ailleurs) les divers principes à appliquer au quotidien pour faire avancer leur carrière ou améliorer la manière dont ils gèrent leur travail. Et avec le temps, je me suis rendu compte que ces principes peuvent au final être résumés en 3 points clés :

  1. Simplicité
  2. Communication
  3. Passion

Évidemment, ils ne suffisent pas à donner toutes les directions à suivre. Mais si, jour après jour, chaque action est guidée par ces 3 principes, on se rend compte que l'on fait naturellement de bien meilleurs choix. Je me suis surpris moi-même récemment, au moment de prendre certaines décisions, à me demander «N'est-ce pas trop compliqué ? Qui dois-je en avertir et avec quel niveau de détail ? Ai-je vraiment envie de faire ça de cette manière, y ai-je consacré l'attention nécessaire ?». Et cela m'a permis de revoir certains choix de façon éclairée.

Voyons voir en quoi tout cela consiste.

Simplicité

La simplicité est un concept important mais trop souvent sous-estimé. Pourtant, il est valable à tous les niveaux.

Quelques exemples qui seront plus parlant :

  • La modélisation d'un composant logiciel, d'une base de données, d'une API gagne toujours à être la plus simple possible. L'histoire est jonchée de technologies diverses, de protocoles réseaux, qui ont disparu par "sélection naturelle". À chaque fois que quelque chose est trop compliqué, d'autres technologies plus simples à mettre en œuvre apparaissent. Alors réfléchissez à vos propres développements : s'ils ne sont pas aussi simples qu'ils le pourraient, c'est vous qui allez souffrir à l'avenir.
  • L'offre de produits/services de votre entreprise doit être aussi facile à comprendre que possible pour vos futurs clients. Les offres à tiroirs et les options complexes n'inspirent pas confiance, ils ne donnent pas envie d'acheter. Assurez-vous d'avoir un discours clair et limpide.
  • Vous n'arrivez pas à faire en sorte que votre équipe utilise correctement le coûteux logiciel de gestion de projet que vous avez mis en place, malgré toutes les fonctionnalités hyper-géniales qu'il offre ? Incitez-les à utiliser correctement des outils simples, pour commencer ; donnez-leur un bloc-note à chacun pour noter leurs todo-lists, et gérez vos projets à coups de post-its collés sur un mur visible par tout le monde. Puis introduisez graduellement les outils plus structurés.
  • Vous n'arrivez pas à vous faire comprendre en réunion, vos idées sont systématiquement mises de côté ou on ne vous accorde pas tout le crédit que vous méritez ? Peut-être êtes-vous un peu trop brouillon, vous n'arrivez pas à agencer votre discours. Simplifiez-le ! Ne laissez pas les idées se précipiter toutes en même temps, prenez soin de les trier dans votre tête avant d'en exprimer les grandes lignes avec des phrases courtes.

Vous connaissez l'adage : on n'a pas atteint son but quand il n'y a plus rien à ajouter, mais quand il n'y a plus rien à retirer. Adoptez une approche zen.

Communication

Une bonne communication est nécessaire en toutes circonstances. Quelques exemples :

  • Quand vous développez une brique logicielle, il est nécessaire de la documenter. Si personne n'est capable de l'utiliser, et si vous-même n'êtes pas capable de la faire évoluer dans 6 mois, elle ne sert à rien.
  • Les décisions que vous prenez en réunion doivent être notées dans des compte-rendus. Sinon, vous allez fréquemment reprendre l'intégralité de vos cheminements intellectuels pour aboutir aux mêmes décisions. Quelle perte de temps !
  • Quel que soit votre poste, quelles que soient vos responsabilités et vos prérogatives, vous devrez toujours convaincre les autres personnes du bien-fondé de vos décisions. Si vous ne communiquez pas correctement auprès des personnes impactées, vous aurez l'impression de devoir vous "battre" tous les jours sans comprendre pourquoi.
  • Prenez soin de la forme et du fond de vos communications avec vos clients. Vous devez les rassurer sur la qualité de votre travail et sur le fait que leur argent est dépensé à bon escient. Leur montrer que vous faites du bon boulot est aussi important que le boulot réalisé lui-même ; si vous ne leur prouvé pas, ils ne le sauront pas et pourront suspecter le contraire. Cela est valable aussi lorsque le client est interne à votre entreprise.
  • Si vous créer une entreprise ou une activité freelance, vous devrez communiquer auprès de vos clients, partenaires et investisseurs. Vous devez rendre évident à leurs yeux que travailler avec vous est dans leur intérêt.

L'image des informaticiens autistes qui travaillent au fond de leur grotte est maintenant révolue. Nous devons être des professionnels capables de prendre en charge tous les aspects de notre métier (nos métiers !), dont l'expertise technique est l'un des nombreux éléments.

Gardez à l'esprit que, s'il est important de communiquer en quantité et avec qualité, la simplicité reste importante. Vous gagnerez en efficacité si vous êtes clair et concis dans vos échanges et vos communications.

Passion

Dans tous les cas, votre carrière doit être guidée par la passion.

  • N'acceptez pas un poste qui ne vous motive pas, juste parce qu'il est bien payé ou bien situé géographiquement. Vous dépérirez chaque jour un peu plus.
  • Lorsque votre boulot ne vous offre plus rien de passionnant, que vous ne vous y éclatez pas, il est sûrement le temps d'en changer. Cela peut être fait en interne ou en changeant d'entreprise. Mais ne laissez pas ce genre de situation s'installer dans la durée.
  • Cultivez vos passions, enrichissez-les et elles vous enrichirons à leur tour. Développez vos talents, intéressez-vous à des sujets variés. Ne vous laissez pas envahir par le train-train et les habitudes.
  • Communiquez autour de vous votre passion pour le travail que vous faites. Donnez aux autres l'envie de bien faire. Montrez l'exemple et devenez une locomotive.

Aimez votre métier, entretenez cette passion et transmettez-la autour de vous.

Et avec tout ça ?

Quand j'ai réalisé que je tenais là les 3 points clés de toute activité personnelle ou professionnelle, j'ai commencé par faire des points mentaux réguliers. Le midi et en fin de journée, tout en vérifiant ma liste de tâches et celles de mon équipe, je passais en revue ce que j'avais fait auparavant et je me demandais si j'y avais mis toute la simplicité, toute la communication et toute la passion dont j'étais capable.
Et avec le temps, ça devient une gymnastique automatique. Essayez !

Pour l'anecdote, on m'a fait remarquer une fois que ces 3 principes pouvaient ressembler à des conseils conjugaux. Eh bien... à vrai dire, c'est vrai qu'une vie de couple équilibrée réclame elle aussi simplicité, communication et passion. Est-ce étonnant que cela s'applique aussi à votre travail, où vous allez parfois passer plus de temps qu'à la maison ?

aucun commentaire aucun rétrolien

mercredi 27 janvier 2010

Skriv : Identification et prix

Par Amaury le mercredi 27 janvier 2010, 15:42 - Skriv

(ce billet fait partie d'un ensemble consacré au projet Skriv)

J'ai rassemblé sur ce billet deux sujets différents et au final pas très importants − par rapport aux fonctionnalités ou à l'ergonomie, par exemple − mais dont je voulais parler quand même. Comme ça on pourra ensuite se concentrer sur le plus important.

Création de compte et identification

Il faut évidemment permettre la création de compte directement sur le site. Mais ce serait une bonne idée d'autoriser l'identification par des procédés d'authentification centralisés. Le premier qui me vient à l'esprit est OpenID, qui est un protocole standard prévu exactement pour cela. On peut y ajouter le Google Federated Login (basé sur OpenID), Yahoo! OpenID, Windows Live ID (basé sur OpenID lui aussi), l'identification centralisée de Twitter (utilisant OAuth), ou encore Facebook Connect.

Ces systèmes permettent de créer un compte quasi-instantanément. Il suffit de cliquer sur le bouton "Google", on arrive sur une page chez Google qui nous demande si on veut continuer (pour peu qu'on soit déjà identifié chez Google), on clique sur "Oui", et hop ça y est. C'est assez séduisant.

Ensuite, il faut voir la complexité d'implémentation de chaque protocole. Google, Yahoo! et Windows Live ne supportent que l'OpenID version 2. Ça a l'air idiot, mais les bibliothèques de connexion OpenID ne sont pas si nombreuses en PHP. Il en existe une très simple, qui fonctionne très bien, mais uniquement pour OpenID 1. Il en existe une autre, très complète mais lourdingue à mettre en place, qui est censée être pleinement compatible avec OpenID 2 (mais qui ne semble quand même pas fonctionner avec Google ni Yahoo!).
Pour Google, ce n'est pas un problème : Le Google Federated Login est très bien documenté, et j'ai trouvé une librairie qui s'y connecte directement, sans assurer de compatibilité OpenID, et ça fonctionne très bien.

J'hésite beaucoup pour Facebook. Vu le nombre de personnes ayant un compte Facebook, ça semble intéressant. Mais Facebook Connect est quand même assez galère à mettre en œuvre. Il faut créer une application, et les utilisateurs doivent accepter que cette application accède à leur compte. Et il faut mettre en place du cross-site scripting, pour que la partie Javascript de l'identification puisse accéder aux deux sites sans perdre de cookie. Bref, c'est casse-bonbon.
Mais il reste un espoir : Facebook s'est rallié au protocole OpenID. Pour l'instant, il n'est pas possible d'utiliser Facebook comme serveur OpenID, mais cela pourrait arriver à l'avenir.

Concernant Windows Live... Bah si ça fonctionne, c'est tant mieux. Si ça ne marche pas, je ne vais pas pleurer, je n'ai pas l'impression que ce soit un besoin si important que cela.

Pour résumer, la priorité est pour moi d'offrir l'identification par OpenID 1.0, Google, et si possible Twitter. Bref, ceux qui peuvent être mis en place facilement, et pour lesquels il existe des librairies faciles à utiliser. Si c'est pour déployer des usines à gaz et perdre du temps qui serait utile au développement des vraies fonctionnalités, autant laisser tomber.

Coûts et prix

Comme je l'ai déjà dis auparavant, je suis attaché au fait de ne pas faire payer l'accès au service. Je suis toujours éberlué de voir des outils faire payer pour des choses qui n'ont aucun coût réel, comme l'encryption SSL, le nombre d'utilisateurs autorisés, le nombre de projets gérés, le nombre de pages, ...

Évidemment, avoir un serveur qui tourne et qui héberge le service a un coût. Mais on va simplifier les choses à ce niveau. J'ai déjà un serveur qui fait tourner un certain nombre de sites. De la même manière, toutes les données textuelles sont stockées en base de données ; elles prennent de la place sur disque. Mais là aussi, on peut se dire que c'est assez négligeable.

Par contre, il y a des fonctionnalités qui peuvent avoir un coût direct en fonction de leur utilisation. Et dans ce cas, je préfère laisser aux utilisateur le contrôle de leurs dépenses. J'ai pour le moment 2 cas précis en tête :

  • Le stockage de fichiers. Il y aura sûrement la possibilité d'associer des fichiers aux projets gérés dans Skriv. Et ça peut vite représenter des centaines de méga-octets, voire des giga-octets. Plutôt que de prévoir une gestion de l'espace disque sur le(s) serveur(s), et de facturer cet espace (à quel prix ?), il me semble plus simple de laisser chacun se créer un compte sur Amazon S3. Ainsi, chaque utilisateur paiera directement à Amazon en fonction de la taille des données stockées et de la quantité transférée.
  • L'envoi de SMS. Je n'ai pas encore bien en tête la fonctionnalité qui irait derrière, mais on peut imaginer un "reminder" qui fonctionne aussi bien par email que par SMS. L'envoi de SMS a un coût directement lié au nombre de SMS envoyés. Là encore, les utilisateurs qui comptent utiliser cette fonction pourraient s'abonner à un service comme SMSMode ou Clickatel, puis enregistrer leurs paramètres.

Au sujet d'Amazon Web Services, on pourrait imaginer y stocker la base de données, et laisser ainsi chaque utilisateur payer en fonction de la quantité de données stockées (comme pour les fichiers stockés sur S3). Mais non seulement cela obligerait tous les utilisateurs à devoir se créer un compte sur Amazon − et le configurer correctement −, mais en plus cela ralentira l'ensemble du fonctionnement du service (quoi qu'on en dise, rien n'est plus rapide qu'une base de données qui tourne en local).

Pouvez-vous imaginer d'autres cas ? Quels peuvent être les coûts qui se cachent dans un web-logiciel de ce genre, et comment pouvons-nous les contourner intelligemment ?

9 commentaires aucun rétrolien

samedi 23 janvier 2010

Lancement du projet Skriv

Par Amaury le samedi 23 janvier 2010, 21:45 - Skriv

J'en parlais récemment dans le post concernant l'avenir de ce blog : Je réfléchis à l'idée de développer un outil de gestion de projet ouvert à tous.

Quasiment depuis que je travaille, j'ai développé des outils pour suivre les projets ou traiter les bugs. Comme j'ai souvent bossé dans des entreprises de petite taille, pour ne pas dire des start-ups, ces outils comblaient des manques évidents et étaient adoptés rapidement.

  • Il y a maintenant un paquet d'années, j'avais fait un gestionnaire de buglist. Doté d'une interface web, il était écrit en C et stockait ses données dans un fichier XML. Technologiquement, ce n'était pas une très bonne idée, mais c'était l'occasion de tester des librairies XML et CGI que j'avais écrites en C. Au niveau des fonctionnalités, je ne me souviens plus trop. Je crois que c'était assez simple, avec pour chaque bug le niveau de criticité, une description, et le projet affecté.
  • J'avais par la suite repris le même genre d'outil, mais écrit en PHP/MySQL. Pus facile à faire évoluer, je n'ai pas souvenir qu'on l'ait utilisé à son plein potentiel.
  • Dans mon entreprise actuelle, j'ai dès le début mis en place des outils open-source, les plus important étant Flyspray pour la buglist et MediaWiki pour le wiki. Depuis, j'ai développé des extensions MediaWiki qui nous servent à gérer les projets. Ainsi, chaque projet a une page dédiée sur laquelle apparaissent : la liste des bugs du projet, une liste de tâches, des pages wiki liées au projet, et des fichiers en "pièce-jointe".

Cette extension est clairement inspirée par Backpack. J'aime vraiment ce logiciel. Par rapport à d'autres outils plus orientés "projet", comme Basecamp par exemple (pour reprendre un autre logiciel développé par 37signals), j'apprécie le fait que toutes les informations soient regroupées sur une seule page.
Habituellement, les logiciels de gestion de projets offrent plusieurs vues différentes, chacune pour un type d'information. Il y a un onglet pour les tâches, un onglet pour le calendrier, un onglet pour les bugs (si l'outil les gère), un onglet pour les pages de wiki (si c'est disponible), un onglet pour les fichiers, et ainsi de suite.
Pour ma part, je préfère avoir la vue la plus "intégrée" possible. Cela implique de penser l'interface en conséquence, ce qui peut s'avérer plus délicat qu'il n'y paraît.

Je cherche donc maintenant à définir un outil que je pourrais utiliser aussi bien pour mes besoins en entreprise, que pour gérer mes projets personnels. Je vais donc m'intéresser à chaque aspect d'un tel logiciel dans une série de billets sur le blog. Je ferais appel aux avis des lecteurs du blog, en espérant réussir à dégager des principes clairs de fonctionnement. J'espère aussi trouver le temps de développer ce logiciel, pour que tout cela ne reste pas théorique (d'un autre côté, si un autre outil est développé à partir de spécifications dérivées de mes idées, je n'y verrais aucun problème, bien au contraire).

Ah, au fait, pourquoi appeler ce projet «Skriv» ? C'est un nom que j'affectionne, que j'ai donné par le passé à plusieurs logiciels que j'ai développé. Le plus important était une interface web qui intégrait un webmail, un gestionnaire de bookmarks, un bloc-notes, un carnet d'adresses, une gestion de compte bancaire. Je l'utilisais tous les jours pour centraliser ma vie numérique. De nos jours, c'est assez commun ; mais à l'époque où je l'ai développé (en 2002), c'était assez novateur.
Pour le nom lui-même, il signifie "écrire" dans plusieurs langues comme le breton et le suédois. Ça va bien dans l'idée d'un outil qui sert principalement à communiquer.

11 commentaires aucun rétrolien

jeudi 14 janvier 2010

Faire des choix

Par Amaury le jeudi 14 janvier 2010, 21:44 - Création d'entreprise

Une idée assez connue, mais tellement importante :
« Il faut faire des choix à la place de l'utilisateur. »

J'en ai eu encore récemment un exemple, en travaillant sur la refonte d'une page d'un site Web. La page en question présente un certain nombre d'informations, dont des contenus écrits par les visiteurs du site. La question qu'on se posait était de savoir comment présenter ces contenus : valait-il mieux afficher les plus récents en premier, ou les mieux notés, ou ceux dont le créateur a un statut privilégié sur le site ?

Quelqu'un dans l'entreprise a proposé “Nos goûts ne sont pas forcément ceux des internautes. Ne faisons pas de choix, donnons-leur les options pour qu'ils choisissent eux-mêmes.” L'idée est séduisante et facile. S'il semble trop complexe de choisir entre différentes options, laissons les utilisateurs se débrouiller, ils y arriveront mieux que nous.

Mais non, ça ne fonctionne pas. D'abord parce que 95% des visiteurs (si ce n'est pas plus) ne prendront pas la peine de changer l'affichage par défaut. Donc il faut de toute manière peaufiner cet affichage par défaut.
Je ne dis pas qu'il ne faut pas proposer d'options, accessibles via un menu par exemple. Mais même ainsi, il ne faut pas lister tous les choix possibles, juste parce qu'on peut le faire. Il faut se limiter aux options utiles.
L'idéal reste dans tout les cas de réussir à trouver LE bon équilibre, qui remplira à 100% le besoin de la majorité des utilisateurs. Ce n'est pas grave si moins 5% de vos visiteurs sont satisfaits à seulement 80%.

Prenons deux exemples :

  • Est-ce que le site Digg aurait autant d'intérêt si l'écran d'accueil offrait un simple affichage par date ou par note ? Évidemment que non ! Ce qui rend Digg utile, c'est son algorithme de recommandation.
  • Le logiciel Picasa de Google offre des options de traitement des images, comme la plupart des logiciels de ce type. Mais il propose une option "J'ai de la chance" qui tente de faire les choix les plus judicieux. Et la plupart du temps, ça marche !

Alors faites des choix, guidez vos utilisateurs vers la meilleure solution. Qui mieux que vous, expert du sujet, peut faire ces choix ? Quand vous proposez des options ou des outils supplémentaires, n'ajoutez pas toutes les fonctionnalités que vous pouvez imaginer. Attachez-vous à proposer les bonnes.

5 commentaires aucun rétrolien

- page 1 de 17