Catégorie : Travail

Sur certains projets, on s'investit tellement qu'on a envie qu'ils marchent.
Bien sûr, on passe par des phases de doutes, on ne sait pas trop si ça va marcher, on ne sait plus. Mais on fait quand même.

Ce projet est une commande de La Communication Directe, qui m'a trouvé sur google au mois de décembre dernier. Il m'a fourni un cahier des charges que j'ai lu et annoté pendant un week-end à Lyon. Retour sur Besançon pour lui faire un devis. J'étais en concurrence avec 2 autres entreprises (pas des freelance) : j'étais plus cher et plus long. J'ai eu le contrat car j'avais donné la sensation de maîtriser plus ses attentes que les autres. En effet, je travaillais déjà (et je travaille toujours) sur la refonte d'un site du même genre.

Parlons un peu du projet à proprement parlé : WikiJournal est un site national désireux d'être proche de vous. Pour cela, tous les contenus sont localisés par régions, départements et 'pays'; on peut consulter le site au niveau national ou bien au niveau de chaque région. C'est la vision du client. Dans ce journal, on y trouve des articles présentant les régions, ce qu'on peut y faire, etc... Il y a aussi des petites annonces gratuites pour vendre ou acheter ce que vous voulez, un agenda local pur annoncer vos manifestations ou trouver de quoi faire ce week-end et un annuaire professionnel pour trouver votre plombier.

Dans chaque partie, vous pouvez soit consulter les ajouts effectués par les utilisateurs par catégories et/ou par localisations, mais aussi en ajouter par des formulaires qui sont à la fois simples, concis et faciles d'utilisation. Tous les ajouts et modifications doivent être validés pour apparaître sur le site.
Pour ce faire, le client dispose d'une administration protégée, dont j'ai fait le graphisme depuis un design récupéré sur OSW. Voici le résultat :

Ici pour les petites annonces. Evidemment, il n'y en a pas beaucoup, le site vient tout juste d'être lancé.
Comme à mon habitude, j'utilise TinyMCE (que j'affectionne particulièrement) dans l'administration pour gérer des pages fixes du site, ou le contenu des articles.

Il y a beaucoup d'Ajax dans le site. Par exemple, pour recharger les liste déroulantes lorsqu'on sélectionne une nouvelle localisation. Ce n'est pas la première fois que j'en fait, mais c'est le premier projet où il y en a autant.

Un gros travail a été fait pour optimiser le référencement. Si vous regarder les URLS des pages de résultats, vous verrez par exemple ceci :
http://www.wikijournal.fr/articles,r11,Midi_Pyrenees.html
http://www.wikijournal.fr/articles,r16,Provence_Alpes_Cote_d_Azur.html
On ne sait pas encore trop ce que va donner cet URL Rewriting, mais c'est toujours plus beau que des paramétres passé en GET. Bien sûr, un travail similaire a été fait sur les titres des pages, qui reprennent à peu près le même principe.

De plus, tous les formulaires d'ajout de données (ou de contact) utilise un captcha fait maison pour éviter tout pourrisage par des robots malveillant. En voici un exemple :

Et où gagne-t-il de l'argent ?
Il mise tout sur 2 choses :

• Les Google Ads qui sont présentes un peu partout, plus ou moins dominantes. Personnelement, je les trouve pas vraiment envahissante.
• Les bandeaux publicitaires, qu'il n'est pas encore possible d'acheter; ce sera possible un peu plus tard, quand le site aura grandi. Lorsqu'on achète un bandeau, la personne désirant affichée sa pub pourra sélectionné la partie du site, la catégorie de la partie, mais aussi la localisation où il veut afficher sa pub. Ainsi, il peut cibler ces affichages et avoir un retour sur les clics plus intéressants

J'ai aussi mis en place PhpMyVisites pour qu'il puisse suivre ses visite au jour le jour. Il commence déjà à regarder quelles recherches tapent les visiteurs qui arrivent son site, et à le paramétrer pour ne pas se prendre en compte dans les stats. Cet outil est vraiment adaptéà n'importe qui !

Dans une étude récente publiée par SitePoint et Ektron, on voit qu'Ajax prend de plus en plus de place, et qu'il tendrai même à être plus utliser que Flash.

On peut y voir aussi que plus de la moitié valide la majeure partie de leur création, près de 40% utilisent DreamWeaver (Ouch...) 67% utilise le PHP, 26% ont un blog, etc...

Bref, consultez l'extrait gratuit en ligne, 25 pages de graphiques de ce style, pour savoir quelles sont les tendances...

Via le monde informatique

En ce moment, je travaille sur pas mal de projets en même temps, et je m'aperçois que j'ai quasiment autant de façon d'échanger avec les clients que de projets.
- Le premier est un vieux client, que j'ai depuis maitenant 2 ans. Je ne l'ai jamais vu en vrai, le seul contact que j'ai avec lui est l'email. Tous les devis, demandes de modifications, rapport de bugs etc... se font par mail. A vrai dire, c'est intéressant pour apprendre à bien se faire comprendre. Cela pose bien sûr le problème inverse, il faut que le client me comprenne bien. C'est pourquoi, je me répète souvent dans mes emails, demandant des confirmations. Un autre système que j'ai trouvé est le suivant : le client m'expose son projet, avec ces mots à lui. Ensuite, je lui réponds en reformulant tout ce qu'il veut faire, en lui demandant si c'est bien ce qu'il veut. Si c'est le cas, je peux me lancer dans le projet sans trop avoir de surprises...
- Le second type d'échange est pour un projet un peu plus conséquent, plus difficile à appréhender. Au début, on avait essayer de communiquer aussi par mail, mais je me suis vite aperçu que je ne saisissai pas assez bien ce que voulait véritablement le client. Nous nous sommes donc rencontrés pour qu'il m'expose clairement ce qu'il voulait, en même temps que je le questionnait sur les points que j'aurai besoin d'éclaircir pour faire ma programmation. C'est ici un gros avantage : je me rends compte directement des questions que j'aurai à me poser, et je les pose directement au client et je note sa réponse sur la calepin pour les ressortir au moment voulu. Nous nous voyons environ une fois par semaine, pour faire le point sur ce qui a été fait et validé, puis pour discuter des prochaines étapes du développement du site. Entre 2 rendez-vous les échanges se font par mail, un peu comme le permier exemple. La plupart du temps, un email contient plusieurs points du site. Pour y répondre, je réponds directement dans son email, avec une autre couleur pour plus de clarté, pour répondre point par point à ses questions/remarques. Ensuite, s'il y a encore des questions sur ce que je réponds, il utilise le même procédé, et ainsi de suite, jusqu'à ce que le point disparaisse, ayant été traité et mis en place sur le site.
- Le troisième est un client qui utilise internet, mais qui est beaucoup plus adepte du téléphone. Du coup, dès qu'il a une question ou une remarque, il me téléphone (jusqu'à 5 coups de fils en moins de 3 heures) et il m'expose son problème, on en discute, et je lui propose une solution technique à son problème, pour que ça lui convienne. Sur ce projet, j'ai aussi un contact par MSN avec le graphiste, je le tiens au courant sur quels fichiers je travaille et des modifications à apporter.
- Le quatrième est un projet au sens véritable du terme. Pour ce dernier, j'ai eu une réunion avec le commanditaire pour qu'il m'explique bien (et que je comprenne bien) ce que je devais faire, avec documents écrits des tâches à accomplir. Ensuite, je suis totalement libre, sans contact particulier avec lui, sauf si j'ai un point à éclaircir (ce qui n'a pas encore eu lieu) et à la fin du projet, il validera l'ensemble de mes travaux ou m'indiquera quels points sont à modifier.
- Enfin, le cinquième projet (qui touche bientôt à sa fin) avance lentement, car le client n'est pas très présent. Il ne reste que quelques petits détails à revoir mais qui demande l'intervention de ce client. Donc forcément, le site n'avance pas.

Sur tous ces projets, le système de communication que je préfère est sans doute l'email. En effet, quoi de plus frustrant de recevoir un coup de téléphone alors qu'on est en plein développement d'un élément charnière du code, de devoir s'arrêter net pour répondre, puis de changer de projet pour se mettre sous les yeux le projet dont parle l'interlocuteur, puis d'effectuer les petites modifications qu'il demande pour être sûr de ne pas les oublier, et de revenir à son code du début, en étant obligé de le relire pour être sûr de ce que l'on fait.
L'email a cet avantage que l'on y réponds quand on veut, ce qui permet de pouvoir mieux gérer son temps, de se consacrerà un projet particulier le temps qu'il nécessite et régler les petits détails à d'autres moments, où l'attention n'y est pas la plus grande.

Quel est votre avis ? Comment préférez-vous communiquer avec vos clients ? Pour quelles raisons ?

Pour un client, je travaille actuellement sur un site hébergé chez online.net, 1 hébergement M ou L. Etant donné que le site changera pour aller sur un beau serveur dédié tout neuf, je ne me suis posé aucune question sur les ressources utilisables lors de mes requêtes MySQL. Bref, tout allais très bien dans le développement de ce site : déploiement des classes appropriés, développement de classes spécifiques pour ce site, etc...
Aujourd'hui, je me suis attaqué à un listing, qui demande 5/6 jointures de tables, avec à chaque fois 1 clause ON sur la jointure.
J'écris ma requête dans mon fichier PHP, j'upload mon fichier sur le FTP, et j'appelle cette page avec FireFox. Habitué à ce que le site réponde lentement, je patiente quelques instants. Un peu plus que d'habitude cette fois-ci.
Enfin, la page s'affiche, avec une erreur MySQL. Pas inquiété, je lis l'erreur retournée :

The SELECT would examine too many records and probably take a very long time. Check your WHERE and use SET OPTION SQL_BIG_SELECTS=1 if the SELECT is ok

Et voilà. Alors là, je me vois bloqué sur le développement de cette partie, parce que le serveur MySQL d'Online n'arrive pas à suivre.
Actuellement, j'essaie d'exporter toutes les données vers mon ordi, pour pouvoir continuer à travailler, mais c'est extrémement long... le serveur est plus que lent, un vrai calvaire... Entre les erreurs de chargements, les déconnection de la base, les erreurs de requêtes dûes à des temps trop long... Mais bon, ça fait partie des aléas du métier...

Du coup, j'en ai eu tellement marre de faire mes développements dans des conditions pareilles que j'ai transférer tout le site (fichier PHP et Base de donnée) vers un serveur dédié pour d'abord comparer les temps de réponses dans un premier temps, puis faire tous mes tests dessus s'il était plus rapide.
Résultat : un temps de réponse 3 à 4 fois plus rapide, et plus de soucis de requêtes MySQL trop grande...