Photo de samgrover depuis Flickr

Découverte

Lors de la création de mes premières pages web, j’utilisais un outil WYSIWYG et je gérais les alignements comme je le pouvais à coup de marge plus ou moins épaisse, de toutes façons, je ne me préoccupai que du rendu d’IE 5, et vu ce que l’on trouvait à l’époque sur le web, ce n’était pas si mal.
Le passage à une écriture de code à la main, m’a permis de supprimer toutes les fioritures inutiles ajoutées par mon outil précédent. Je me suis vite rendu compte que le résultat était tout de même plus joli, mais basique.
L’arrivé de nouveaux navigateurs à compliqué la donne, le rendu approximatif se révélant au mieux presque correct, au pire vraiment aléatoire.
J’ai toujours souhaité travailler avec un code propre, en évitant les hacks pour corriger les défauts d’implémentation des navigateurs, j’estime que ce n’est pas à moi de le faire. Mais si je peux avoir un code qui passe partout, je ne m’en prive pas.
Et peu à peu ma veille permanente m’a fait découvrir des techniques de mise en page plus évoluées. J’ai suivi cela de plus ou moins loin, en n’en gardant que la théorie, mais sans mettre plus que cela en pratique. Il me semblait clair que c’était une voie à étudier, une solution à mette en œuvre, mais il y a tellement de chose à faire…

Révélation

La conférence sur la micro-typographie de David Rault m’a rouvert les yeux L’illumination est venue d’Anne-Sophie Fradier. Je ne reviendrai pas sur la qualité de sa prestation à Paris Web 2010, mais sur la pertinence du contenu, qui m’a définitivement donné envie de m’y mettre. En une heure elle me présentait un condensé de ma veille avec de jolis exemples, je ne pouvais plus éviter le sujet. Cela tombe bien j’avais un site dont j’étais globalement content, avec des pistes graphiques intéressantes, mais qui pêchait sur certains aspects, et je voyais bien que j’étais désormais dans la bonne direction !
Il ne me restait plus qu’à laisser mûrir tout en me remettant activement dans la technique.

Mise en situation

Vincent Valentin à eu la bonne idée d’écrire à ce moment une série de billets qui m’ont enthousiasmé, et guidé dans mon entreprise. Il y reprend la partie technique avec des exemples précis, un vrai retour d’expérience, sur les outils qu’il utilise et surtout pourquoi. Il y explique le cheminement de ses réflexions, bref comment il travaille. Bien sûr, lui est intégrateur, moi je fais juste de l’intégration. Il m’a donc fallu plusieurs lectures, et quelques autres billets pour bien me remettre au goût du jour, et j’ai commencé par tâtonnements à reprendre mon projet.
Après quelques essais, j’ai décidé de ne pas tout utiliser, et j’ai laissé de coté Les grilles toutes faîtes, et les compilateurs CSS. Les premières car l’utilisation avec les media-queries me semblaient ajouter de la complexité (même si Vincent propose une solution) le second car c’est un projet simple, inutile de trop compliquer la tâche. Cela viendra donc dans un second temps.

Mise en pratique

Le projet initial était finalement assez simple, avec quelques images, mais finalement, beaucoup de dégradés ou de coins arrondis. L’alignement sur la grille ne poserait donc pas trop de problème en découpe d’images.
Je suis donc reparti de feuilles de styles vides, et quitte à reprendre le code en y ajoutant une dose de CSS3, autant revoir le balisage et passer à HTML5. Cette partie fut vite expédiée. La lecture récente des deux premiers opus de la collectionA book apart m’ayant remis les idées en place sur le sujet.

J’ai ensuite pris le temps de tester plusieurs largeurs de grilles et de colonnes avant de trouver mon bonheur, avec une possibilité de mettre en page sur une, deux, trois ou cinq colonnes (Il existe du coup d’autres possibilités que je n’utiliserais pas, restons simples, à mon sens trop de colonnes tuent les colonnes).

L’utilisation de Hashgrid a été précieuse pour cette partie du travail, en me permettant de visualiser l’invisible.

Certaines pages de contenu ne me convenaient pas du tout, mise en page simpliste, alignements maladroits, même si au premier abords, je n’aurai su dire pourquoi et comment le corriger. Je ne suis pas non plus graphiste…
J’avais bien prévu de les refondre, mais comment ? Finalement c’est venu tout seul… Sans rien faire d’autre qu’utiliser ma grille pour remettre en place les différents blocs de contenus, tout s’est éclairci, et au fur et à mesure les textes se sont mis en page aidés par la grille horizontale et par la grille verticale. Tout en gardant un rendu « simple », le tout devenait harmonieux (à mes yeux, pas vous ? mince…)
Le travail en parallèle sur les polices et les hauteurs de ligne, a bien aidé, et à même simplifié le travail. La règle ajoute des contraintes, oblige à se plier à certaines obligations, mais au final, libère ! Plus de rendus approximatifs, plus d’hésitations, on se fie à la grille et c’est tout. Finis aussi les effets de bord quand on ajuste d’un côté et que casse de l’autre…

Il y a pour moi trois étapes :

• L’ignorance de la règle
• Son apprentissage et sa mise en application
• Son appropriation et son contournement

Et un outil, si bon soit il doit être utilisé à bon escient. Pas question d’appliquer bêtement une règle, une réflexion s’impose. Alors bien sûr il m’est arrivé de contourner certaines règles. Les raisons sont variées, mais tout ne peut pas rentrer dans une grille, parfois quelques éléments ont besoin de plus ou moins de place, à l’œil, on sent que quelque chose ne passe pas bien ,que tout est trop rigide… Il faut donc s’échapper du carcan, pour trouver la solution. Il faut trouver une exception, la règle a beau l’air parfaite, il existe des cas particuliers. Il s’agit alors de ne pas faire n’importe quoi, au risque de perdre une partie du bénéfice acquis, mais de trouver une justification raisonnable qui apporte une solution au problème. Et j’ai finalement souvent trouvé cette solution dans d’autres grilles, dans des « sous-grilles », en répétant ma grille d’origine différemment, en appliquant les mêmes marges mais autrement…

La macro-typographie ça marche !

Retour d’expérience

Au final, il m’aura fallu quelques heures/jours de montée en compétence entrecoupées de temps de réflexions, d’essais pratiques, et de remise en question pour arriver à mon résultat. Il reste encore du travail, tout n’est pas fini, l’adaptation aux navigateurs mobiles est en cours, mais il est déjà temps d’en tirer des conclusions.
Je retiens que si j’y ai passé du temps au début, je n’en ai pas perdu pour deux raisons :

• Le résultat final est meilleur
• J’ai gagné du temps sur d’autres aspects de l’intégration

Et sur mes prochains projets, ce sera encore plus vrai.

Ressources

Billets

• Macro typographie sur le Web – une grille dynamique
• Macro-typographie sur le Web – Mise en pratique
• Macro-typographie sur le Web – Quelques outils
• http://snook.ca/archives/html_and_css/font-size-with-rem

Vidéos

• conférence sur la micro-typographie
• sa prestation

Alors que dire de plus, regardez les vidéos, lisez les quelques références ci-dessous, essayez, testez, et dites moi comment vous vous en sortez, ce que cela vous apporte, si cela vous bride ou non…

Moi j’y retourne, j’ai encore un peu de travail…

Sur le même thème

• Bien utiliser les feuilles de style (CSS)
• Optimiser son site web
• Internationalisation & localisation
• Livre : HTML5 pour les webdesigners
• Développer sous Ubuntu

Photo de harold.lloyd depuis Flickr

Pourquoi faire ?

Pourquoi fournir une API ? Si vous lisez cela vous devez déjà avoir une petite idée… Le principe d’Internet c’est le partage, et il existe une multitude de protocoles qui permettent ces échanges (http, ftp, p2p…).
Quel que soit votre activité, son but n’est pas de rester confidentielle, et vous souhaitez sûrement la partager avec le plus grand nombre, le meilleur moyen est de multiplier les manières d’utiliser votre travail.

Que votre webservice fournisse des données (statistiques par exemple) ou des services (calculs, paiement…), il doit trouver son public. En proposant un maximum de possibilités d’y accéder vous augmentez les usages possibles, et surtout vous donnez la possibilité aux utilisateurs de créer des usages auxquels vous n’avez même pas pensé. Votre application devient le vecteur d’usages innovants.

Choisir un format

Les architectures REST ou soap sont très répandues et leur usage est possible simplement via une foule de langages. Vous pouvez rendre votre réponse dans un format défini, mais n’hésitez pas à le rendre paramétrable pour fournir au choix du XML, du JSON ou même du YAML par exemple.
Plus vous proposerez d’options, plus votre API à des chances d’être utilisée ! Vous n’êtes certainement pas le seul à fournir ce genre de service, soyez le meilleur pour garder vos utilisateurs.

Attention à bien penser dès le début aux différentes pistes que vous souhaiter suivre afin de ne pas devoir modifier votre API par la suite et risquer de perdre des clients pour un problème de non compatibilité. Le cas échéant, prévenez les le plus tôt possible et accompagnez les dans la démarche.

Paramétrer

Et tout un tas d’options peuvent êtres ajoutées. Elles peuvent paraitre anodines mais seront d’un grand secours à vos clients. Vous pouvez par exemple leur fournir un compteur d’utilisation de l’API et pourquoi pas un historique des appels. Dans le cadre de prestataires de paiement par exemple, si un callback doit être fait, donnez une liste d’ip publiques afin que le client filtre les appels, donnez lui aussi la possibilité de choisir le nom des variables renvoyées, et pourquoi d’en ajouter… Si les données sont sensibles ajouter une clé secrète et un hashage des données pour certifier les données.

Ne mettez pas n’importe quoi mais restez à l’écoute des demandes, il y a sûrement des cas auxquels vous ne pensez pas, mais qui sont indispensables à vos utilisateurs.

Afin de gérer certaines options, l’accès à un back-office devient nécessaire, ca complique légèrement la tâche mais cela permet de faciliter les échanges avec votre cible. Vous pourrez ainsi collecter un email, attribuer une clé d’API, paramétrer l’API, communiquer avec l’utilisateur, lui fournir des infos statistiques sur son utilisation… Et récolter un maximum d’information pour améliorer votre service.

Sécuriser & tracer

La clé d’API à deux intérêts, limiter l’accès à certaines données ou services à certains clients, et tracer l’utilisation de chacun afin d’en extraire des données statistiques. Ces données vous seront utiles pour améliorer votre service en fonction des usages, mais aussi de mettre en place une stratégie de monétisation.

Une clé secrète permet également d’encoder les données afin de sécuriser les échanges pour qu’ils ne transitent pas en clair et de valider que les données en retour proviennent bien d’un tiers de confiance ayant connaissance de la clé.

Monétiser

Augmenter les usages et favoriser l’utilisation de votre API c’est bien, mais il peut devenir nécessaire de rentabiliser le service ou au moins de payer les frais d’infrastructure (serveur, maintenance, bande passante…). La clé d’API intervient encore ici pour permettre de facturer ou limiter les appels.

On peut imaginer une solution ou les 1000 premiers appels mensuels sont gratuits, au delà un abonnement permet de continuer à utiliser le service.

En plus de la clé d’API pensez à vérifier d’autres éléments comme l’ip pour éviter que des petits malins multiplient les comptes pour contourner le système !

Documenter

Avant d’utiliser un webservice, une phase d’analyse est nécessaire afin de cerner les possibilités et les limites de l’API. Cette phase est importante, c’est le premier contact du développeur avec votre produit. Il doit rapidement cerner si il pourra l’utiliser ou pas. Il en a probablement ciblé plusieurs, et ne les implémentera pas tous. Il faut donc le rassurer au plus vite, la documentation est là pour cela. Elle doit à la fois lui présenter le produit, l’API, des exemples, une FAQ… Tous les éléments dont il pourrait avoir besoin sans chercher à droite à gauche.

Pour commencer, une présentation de l’application, et des possibilités de l’API est indispensable pour dégrossir et permettre au lecteur de cerner le sujet rapidement. Ensuite, les pré-requis à l’utilisation de l’API sont nécessaires, avec pourquoi pas les différentes étapes de l’inscription au service. Le but est de faciliter l’implémentation de l’API, que ce soit pour un simple test ou pour un projet en production.

Donner des exemples

Le bla bla c’est bien, mais un exemple ca aide. Avec la mise en place de l’appel à l’API juste avec la documentation, on peut passer à côté d’une subtilité, surtout si le document n’est pas dans notre langue ou mal traduit.
Un exemple de code permet de tester rapidement et de s’assurer que l’appel fonctionne correctement. Les explications permettent ensuite de d’aller plus loin et de jouer avec les options. Je vous dirais bien de mettre cet exemple en PHP pour sa popularité et sa simplicité, mais identifiez bien votre cible afin de fournir les exemples dans les langages les plus susceptibles d’être utilisés.

Fournir une bibliothèque

Pour faciliter l’usage d’un webservice, certains fournissent directement une bibliothèque. Si l’API est complexe cela permet de manipuler facilement les objets et peut simplifier l’implémentation, à condition de répondre au besoin de l’utilisateur. Dans le cas contraire son encapsulation peut s’avérer fastidieuse. Cela peut aussi permettre de déplacer une partie de la logique métier sur le serveur client.
Certains service bancaires offrent la possibilité de compiler directement une extension PHP avec la clé d’API par exemple . On étend ainsi les possibilité du langage lui même et l’expérience utilisateur est excellente. De plus, la clé d’API ou le mot de passe ne sont plus accessibles directement au développeur. C’est un plus non négligeable pour certaines données sensibles.

Fournir un environnement de tests

C’est parfois nécessaire et souvent indispensable. On doit souvent tester l’utilisation dans des conditions similaires à l’environnement de production mais sans contraintes. Toujours avec l’exemple du paiement, l’utilisation d’un numéro de carte bancaire de test permet de simplifier les tests et de simuler les transactions. En règle générale un paramètre supplémentaire à l’appel de l’API permettra de changer de mode et de tester dans des conditions quasi réelles simple à mettre en oeuvre.

Pour conclure…

Les usages de Webservices sont variés, et ces conseils ne sont pas exhaustifs, votre expérience sûrement différente vous a apporté d’autres enseignements, partagez les avec nous !

Sur le même thème

• Opquast : Sites web, les bonnes pratiques
• Trouver un bon hebergeur web, quels critères ?
• Les générateurs de sprites CSS
• Participons à l’utopie web !
• Optimiser son site web

Qui ne s’est jamais plaint de l’omniprésence des publicités, du manque d’ergonomie d’un site, de la laideur d’un autre, de règles floues en matière de gestion de nos données personnelles, d’abus de pouvoir dans les conditions de ventes d’un site en ligne…

Le web est une jungle, de nombreux sites ayant pignon sur rue n’ont que peu de considération pour les internautes… Il existe bien quelques règles, mais la plupart sont soit informelles soit facultatives et personne n’est là pour les faire respecter, alors nous subissons. En dehors du web c’est aussi bien souvent la même chose, les exemples sont partout, mais autant en dehors du web je n’y peut rien, autant sur le web, j’ai mon mot à dire !

En tant que développeur, je participe au web. Je peux donc au travers de mes sites, faire le web dont j’ai envie.

Photo de Castorp Republic’s depuis Flickr

J’envie toujours ceux qui luttent pour de nobles causes, ceux qui donnent de leur temps, ceux qui expriment leurs idées… A mon niveau j’ai souvent l’impression de ne pas faire grand chose, ou pas assez, ce qui suit n’est qu’un début, le sujet peut paraitre futile, c’est tout petit, ca n’empêchera pas d’autres actions plus concrètes, mais c’est déjà ca de pris…

Le web que j’aime…

Et des envies j’en ai plein…

• Un web, joli, bon c’est subjectif, mais j’essaie…
• Un web accessible, ce n’est pas toujours facile, mais avec un peu de travail on peut s’en approcher
• Un web innovant, je ne suis pas obligé de faire des sites « compatibles » avec les navigateurs, je fais des sites standards, chacun est libre d’utiliser un navigateur qui ne l’est pas…
• Un web honnête, mes conditions d’utilisation et de vente sont claires, compréhensibles, écrites dans un français lisible…
• Un web transparent, j’énonce clairement qui je suis, attention, je ne suis pas contre l’anonymat, mais quand je développe un site ou un service, le client doit savoir à qui il s’adresse.
• Un web respectueux, mes utilisateurs peuvent utiliser mon site sans donner d’informations inutiles, juste l’essentiel, et si ils suppriment leur compte, il ne reste rien. Je ne prends que les données qu’ils me donnent volontairement, et je leur permet de connaître ce que je sait d’eux.
• Un web moral, je n’essaie pas de faire de l’argent en me demandant ensuite avec quel contenu, mais j’essaie de monétiser une idée originale.
• Un web transparent, je ne vends pas un service sans le décrire dans ses moindres détails et sans laisser une période d’essai complètement fonctionnelle. Si l’utilisateur n’est pas content cela ne lui coûte rien, il part en connaissance de cause, pas fâché…

J’en oublie peut être, je complèterai au fur et à mesure…

Ce web, j’ai essayé de le créer avec mybabygame, je ne deviendrait probablement pas millionnaire avec mes méthodes qui feraient fuir tous les « rentabiliseurs » du web… D’ailleurs ce n’est pas le but, je voulais juste offrir un service, de la meilleure possible, rendre mes utilisateurs heureux, leur offrir une belle expérience. Évidement, j’en tire un potentiel bénéfice, et heureusement, il récompense mon travail, mais il me semble plus justifié, et, quand mon code sera un peu plus rodé, je pourrais envisager de partager des bouts de code, sous forme de tutoriels pour partager ces longues heures de dev.

Et votre web ? Il ressemble à quoi ?

J’espère que le résultat vous plaira, il reste encore certainement du travail à faire dans ce sens, vous avez certainement des idées pour aller plus loin, j’attends votre avis sur la question…

Sur le même thème

• Fournir un webservice et son API
• Le temps passe vite…
• Livre : Réussir son site web en 60 fiches
• Gandi & Webaaz vous offrent un nom de domaine !
• Recette & environnements de test

Heureusement, dans tout projet digne de ce nom, on met en place des procédures plus ou moins développées pour tester le code dans de bonnes conditions afin d’éviter les surprises et les régressions.

Toute un série de tests permettent de valider le côté qualitatif du projet. Ils sont rarement tous mis en œuvre, souvent partiellement, sauf sur des projets stratégiques, et bien souvent on prend juste l’essentiel. C’est souvent suffisant pour arriver à un résultat correct, même si il en faudrait parfois un peu plus…

Photo de Oncle Tom depuis Flickr

Que tester ?

L’idéal est de tout tester mais certains tests peuvent être décorrélés du reste. La configuration du serveur, les scripts de mise en production ou de maintenance ou encore le paramétrage des noms de domaines ne sont pas nécessaires à toutes les étapes du développement. On peut souvent les tester séparément du reste sans risques, jusqu’à l’assemblage final en pré-production. Sinon que ce soit des tests de bas niveau, dans le code ou fonctionnels, ils permettront de s’assurer que l’on répond le plus précisément au besoin exprimé.

De toutes façon, tout doit être testé, plus ou moins suivant les cas, on n’imagine pas laisser la moindre place au hasard dans ce processus..

Quels types de tests ?

A chaque étape du développement les tests doivent s’enchaîner, de plus en plus précis, pour arriver au final à une application avec un minimum failles.

Test unitaires

Ce sont parfois quasiment les seuls tests réalisés avant la recette. Ce sont les premiers effectués, directement par les développeurs. C’est évidemment une mauvaise pratique de laisser le soin au seul développeur de tester son code et le fonctionnel rapidement entre deux développements. Le test fait en ayant connaissance du code est toujours orienté, et si le fonctionnel était mal compris son application sera forcément à revoir…

Tant que ces tests ne sont pas automatisés ou au moins effectués par une tierce personne et suivis dans un cahier de tests ils sont quasiment inutiles car limités à des cas non exhaustifs et non reproductibles. La création d’un cahier des tests permet de limiter les effets négatifs, mais rend souvent le travail moins intéressant et parfois rébarbatif…

Et certains tests qui touchent à l’ergonomie ou aux bonnes pratiques ne peuvent être faits de manière automatique car ils requièrent une faculté d’analyse et un œil expert. Le recours à un spécialiste du sujet peut s’avérer décisif si le niveau de qualité à atteindre est conséquent.

Tests unitaires automatisés

Qu’ils soient côté serveur ou côté client, l’automatisation et la réutilisation sont leur point fort !

Côté serveur des frameworks comme JUnit ou PHPUnit permettent de tester de manière efficace les fonctions d’un projet. On teste avec différents paramètres en entrée et on vérifie la sortie sans oublier les cas devant générer des erreurs afin de vérifier que le comportement attendu est le bon.

Coté client des outils comme BadBoy ou Sélénium permettent d’enregistrer des macros et de les rejouer à volonté. On s’assure ainsi qu’il n’y a pas de régression fonctionnelles.

Ces tests automatisés peuvent être lancés après l’ajout d’une fonctionnalité ou la correction d’un bug de manière à éviter les régressions. On peut ainsi tester efficacement et complètement les différentes fonctionnalités développées. Ils peuvent aussi être utilisés de manière automatisée sur une plateforme d’intégration continue.

Avec cette méthode, on capitalise énormément, les tests sont rejouables à l’infini par le client qui peut s’assurer de la bonne conduite du projet et même par une équipe différente qui devrait reprendre le développement ou la maintenance.

Les test peuvent même être à l’origine des développements. En les écrivant avant, on s’assure de bien répondre à chaque cas. Le développement sera validé quand tous les tests passeront.

Quels environnements ?

Environnement de test local

Il évolue souvent en cours de route, suivant l’évolution du cahier des charges, des test des développeurs, des différents projet sur lesquels on peut être amené à travailler simultanément. Il n’est pas toujours évident de tout cloisonner et ce n’est pas forcément nécessaire. A ce stade il peut être intéressant pour les différents acteurs d’avoir une plateforme de travail sans liens communs. C’est particulièrement vrai chez un éditeur de logiciels, qui ne maîtrise pas forcément la plateforme cible de ces clients. Cela permet de capitaliser sur des expériences variées et de pouvoir répondre à un besoin différent facilement.

Pour avoir sous la main des environnements divers et variés pour tester différents clients web par exemple, le recours à des machines virtuelles ou « VM » est d’un grand secours. Vous pouvez ainsi avoir facilement sous la main plusieurs OS, et navigateurs dans des versions hétéroclites. Que ces VM soient sur votre poste ou en réseau, accessible à distance, elles vous permettront de faire vos tests dans d’excellentes conditions.

Environnement de recette

L’environnement de recette doit être proche de l’environnement final, au moment du développement il m’est arrivé assez souvent de ne pas connaitre précisément l’hébergement cible, on peut cependant partir sur les bases évidentes. Choix du langage, des version majeures des différents composants, paramétrages… Le but est d’être au plus près possible de la cible, de manière à ne pas avoir de mauvaises surprises par la suite. Évidemment plus tôt on aura une image précise du serveur de production, et mieux on pourra affiner cet environnement.

Environnement de pré-production

L’environnement de pré-production doit être une copie exacte de l’environnement de production, avec un paramétrage exactement similaire et des données de production. Et l’on ne peut transiger sur aucun de ces points ! Il faudra bien sûr veiller à répliquer et documenter immédiatement le moindre changement.

A chaque fois que l’on m’a imposé une différence si minime soit elle, une erreur est apparue en production. Le plus souvent très légère, c’est vrai mais quel intérêt de faire ce test si il n’est pas exhaustif

Conclusion

Les tests doivent être la base de tout développement, qu’ils soient faits de manière humaine ou automatisée, leur régularité permet d’anticiper les dérives et de corriger rapidement les erreurs.
Des contraintes temporelles ou budgétaires viennent souvent limiter leur mise en application, pensez alors à faire valider régulièrement l’avancée du projet par le client, à défaut de tests, c’est à lui de prendre ses responsabilités.

Sur le même thème

• Trouver un bon hebergeur web, quels critères ?
• Bien définir son projet de site web
• Optimiser son site web
• Fournir un webservice et son API
• Maquettage avec Pencil Sketching

Pourtant avec le peu de recul que nous donne le web, des initiatives permettent de hausser un peu le niveau. Les normes du W3C par exemple permettent par leur respect de garantir que le document sera interprétable par tout les navigateurs. Les référentiels d’accessibilité permettent aux utilisateurs ayant une quelconque déficience de pouvoir surfer avec une contrainte moindre. Le projet Opquast propose un référentiel qualité web mais surtout un outil de suivi de la qualité des services en ligne.

Photo de flickrolf depuis Flickr

Présentation

La première version du référentiel à vu le jour fin juin 2004 avec la mise en ligne d’une liste de bonnes pratiques pour l’amélioration de la qualité des services en ligne.
A l’origine de ce projet, Elie Sloïm directeur de Temesis et Fabrice Bonny co-fondateur du site Openweb

C’est un formidable outil de formation, d’explication, et d’amélioration des sites.

Opquast permet de tester aussi bien la qualité de la conception que la qualité d’utilisation. Les techniques étant de plus en plus variées et complexes, une personne seule ne peut pas maitriser parfaitement toute la chaine de développement d’un site web. La liste des bonnes pratiques permet au développeur comme au décideur de vérifier les points principaux classés par domaine. Chaque bonne pratique est détaillée avec un objectif, des solutions techniques et des moyens de contrôle.

Et le petit plus, Opquast est publié sous licence Créative Commons BY-SA.

Voici les différents sites du projet Opquast :

• Opquast.com : OPen QUAlity STandards
• Checklist.opquast.com : Les bonnes pratiques de la qualité web
• Reporting.opquast.com : L’outil de reporting pour évaluer vos sites et communiquer
• Directory.opquast.com : L’annuaire des sites respectant le référentiel
• Opquast.org : L’atelier Opquast

Nouveautés

Le web évolue et la liste a donc été revue de fond en comble par les membres de l’atelier Opquast, qui ont débattu dans la bonne humeur et l’humour mais avec des avis bien tranchés, et toujours un maximum d’arguments. Un consensus nécessaire à donc fini par émerger, c’est la base de ce référentiel. Une période d’appel à commentaires publics à permis d’affiner un peu plus le travail.

Pour le côté pratique, les bonnes pratiques sont désormais filtrables en fonctions de différents critères :

• Modèle VPTCS : Visibilité, Perception, Technique, Contenus, Services
• Processus : prototypage, design, intégration, CMS et développements, rédaction, référencement
• Services : e-commerce, Espaces publics, Newsletter, Syndication
• Thème : Mobile, Internationalisation, Accessibilité, performance, Sécurité, Utilisabilité

Vous pouvez ainsi en extraire les bonnes pratiques d’utilisabilité spécifiques à la phase de prototypage par exemple.

La navigation par tags et le téléchargement des listes aux formats Excel, Open Office ou PDF sont aussi au programme.

Interview d’Élie Sloïm, directeur du projet

Opquast en vidéo

Des présentations du projet et des outils sont disponibles en vidéo :

• Opquast en vidéo sur Dailymotion

Mémento

• Sites web, les bonnes pratiques
• Dépliant 10×21 : 14 pages
• Éditeur : Eyrolles
• Édition : 2ème (22 janvier 2009)
• Collection : Mémento
• Langue : Français
• ISBN-13: 978-2212124569

Ce mémento est tiré de la première version des bonnes pratiques, mais est toujours d’actualité.

Suivre l’actualité d’Opquast

• Le blog Opquast
• Opquast sur Facebook
• Opquast sur Twitter

Mon avis

Utilisateur de la première version dès ses débuts, j’ai toujours été convaincu par ce projet et pas l’enthousiasme qui rayonne autour, et j’ai été très heureux de contribuer à l’élaboration de cette nouvelle version.

J’ai peut être un regard plus critique, avec l’expérience, je me rend compte que je ne suis pas à 100% d’accord avec toutes les propositions, et dans mes évaluations de sites, je garde mon libre arbitre pour décider ce qui me semble bon. Mais ce référentiel m’amène au minimum à me poser les bonnes questions, et c’est essentiel !

Je suis donc toujours convaincu que c’est un excellent outil et qu’il reste encore beaucoup de travail pour évangéliser les développeurs et les décideurs.

Et vous quels outils avez vous à disposition pour qualifier vos sites web et améliorer leur qualité ? Est-ce que l’on vous donne les moyens d’arriver à un résultat de qualité ? Que vous manque t’il pour y arriver ?

Sur le même thème

• Fournir un webservice et son API
• Livre : HTML5 pour les webdesigners
• Les générateurs de sprites CSS
• Veille techno Web de F à Z (partie 2)
• Optimiser son site web

Photo de minusbaby depuis Flickr

Mais il faut surtout se doter des bons outils…

Communication

La communication est la base du travail d’équipe. Il est important de connaître son équipe visuellement. Le contact physique apporte beaucoup dans la relation et facilite les échanges à distance. L’information doit y circuler facilement pour avancer efficacement. Il faut privilégier des points réguliers et pas trop longs pour pouvoir réagir rapidement en cas de problème, garder une certaine dynamique, et garder un auditoire actif.
Il est aussi important de connaître son équipe visuellement. Le contact physique apporte beaucoup dans la relation et facilite les échanges à distance.

Réunion

Rien de pire que les réunions à rallonge ou rien ne se décide, mais elles sont pourtant indispensables pour avancer. L’idéal à mon avis est de les limiter tout en les multipliant. Je m’explique. Moins de réunions longues avec toute l’équipe, mais plus de réunions courtes voire très courtes avec juste les personnes concernées pour faire des points d’avancements, des points techniques…

Pour qu’une réunion soit efficace, elle doit capter les intervenants et les faire participer sans les lasser !

Messagerie instantanée

Que ce soit via MSN ou un protocole XMPP, ou encore via de nouveaux outils comme Google wave, la messagerie instantanée est indispensable au quotidien pour échanger rapidement sur des sujets peu sensibles mais qui nécessitent une réponse simple et rapide.

Mails

Le mail a l’avantage de pouvoir garder une trace des échanges, avec éventuellement un tri par conversations, par projet… Intéressant pour archiver des demandes ou des décisions dont on pourrait avoir à prouver l’existence.
C’est à mon sens uniquement à cela que doivent servir les échanges par email. Ils ne devraient jamais contenir de données sensibles ou stratégiques, mais annoncer leur disponibilité et leur emplacement. Ceci pour des raisons évidentes de sécurité et pour éviter d’avoir de multiples versions de documents en cours d’utilisation.
Si l’on vous envoie un document, des données, classer les sur le réseau dans un wiki, mais pas dans vos mails, ce n’est pas fait pour cela.

Téléphone

A mon avis, très proche de la messagerie instantanée, les mêmes contraintes voire plus si le destinataire de l’appel est absent.
N’oubliez pas de valider les points importants par un mail récapitulatif.

Visio-conférence

Indispensable pour du travail à distance, même si l’on ne s’en sert pas systématiquement, elle apporte un plus, couplée à des outils tels que des tableaux blancs, elle apporte de l’interactivité et simplifie les rapports humains.

Sources & documentation

Tout projet de développement n’existe pas sans sources et documentation. A plus ou moins grande échelle il est vrai. C’est pourquoi il est primordial de mettre en place les outils et les processus associés pour gagner en productivité et en qualité.

Gestion des versions

C’est l’outil de base, et pourtant tout le monde ne l’utilise pas encore. Au forum PHP 2009, pas plus de la moitié de l’audience d’une des conférences n’a levé la main pour dire qu’il l’utilisait. Je m’attendait à du 99%, surtout au regard de l’assistance plutôt « geek ».

Indispensable pour travailler en équipe sur un même projet et en même temps. Même si il faut essayer de compartimenter le travail pour éviter les incohérences qui compliquent les fusions, il est indispensable de pouvoir revenir en arrière ou d’intégrer les modifications d’autres développeurs à son code.

Bien évidemment il faut apporter une attention particulière à l’utilisation de ces outils, sans commentaires de qualité et sans soumissions régulières, l’intérêt s’amenuise…

Gestion documentaire

Bien souvent c’est juste un dossier sur le réseau ou chacun peut écrire et lire des documents au format Word ou Excel. C’est une limitation gênante car à moins d’avoir une rigueur et des process sans failles, il n’est pas évident de tenir à jour ses documents et de les versionner…

Passer un outil de gestion électronique de documents apporte un plus important avec l’ajout de méta données, une gestion des accès et des différentes versions facilitée.

Wiki

Le wiki est également un outil de communication trop souvent négligé. Il est pourtant très utile pour certaines données comme les coordonnées des intervenants sur le projet, une présentation de l’équipe, une présentation complète du projet avec une liste des différents outils et leurs emplacements…

Cet un outil vivant et simple à prendre en main, un vrai plus pour centraliser les informations !

Gestion de tickets

Pour échanger sur les nouvelles fonctionnalités ou les bugs, peu importe qu’on utilise Mantis, Trac ou Redmine, l’important est de l’utiliser et de bien documenter toutes les actions afin d’avoir une traçabilité sans faille, ces données doivent souvent être reprises par d’autres membres de l’équipe qui doivent comprendre ce que vous avez voulu dire ou faire sous peine de voir des régressions ou d’autres bugs surgir…
Et si vous pouvez intégrer le avec votre outil de versionning pour simplifier l’interaction entre les deux.

Intranets, Extranets, Cloud…

Certains Intranets ou Extranet regroupent une partie de ces outils, pour avoir un maximum d’efficacité, ils doivent êtres intégrés et inter-connectés de façon cohérente pour maximiser les

Sur mes projets personnels j’utilise Google Apps qui apporte tout un lot d’outils bien intégrés les uns aux autres et mes permet de gérer ma communication et ma documentation. Avec l’intégration progressive de tous les outils dans cette suite logicielle, elle va encore gagner en utilisabilité et permettre d’accroitre encore la productivité de ses utilisateurs.

Conclusion

Échangez, documentez, normalisez, mettez en place les process pour être efficace ! En un mot, industrialisez les processus, la productivité et la qualité sont à ce prix !

Voilà mon avis de développeur, j’aimerai avoir votre avis, de développeur, de chef de projet, de client… Laissez un commentaire !

Sur le même thème

• La gestion des versions
• MySQL GUI Tools
• Maquettage avec Pencil Sketching
• Les plugins Firefox : Colorzilla
• Comparaison et fusion de fichiers et de dossiers

Photo de Jean-Marc Hardy de 60questions.net

Présentation

La force de ce livre est à mon avis de s’adresser à tous les publics, aussi bien techniques que fonctionnels, MOE ou MOA, débutants ou expérimentés. C’est le résultat d’une écriture simple et d’explications claires. Les auteurs ne rentrent pas dans les détails techniques, mais expliquent les tenants et les aboutissants, et donnent les pistes pour en savoir plus sur le sujet. Le tout est accompagné d’exemples et de références précises.

La qualité Internet : Indispensable et fragile

Le livre tout en couleurs est agréable à lire, soit du début à la fin; idéal pour une première lecture, soit en cherchant le sujet qui nous intéresse grâce à un index précis.

On aborde ainsi aussi bien les performances web, que la qualité du contenu, du design ou l’impression des pages…

Chaque fiche présente ainsi :

• Une courte introduction
• Un conseil argumenté
• Des citations
• Des chiffres statistiques pour étayer le propos
• Une étude de cas comparée
• Des références & outils pour aller plus loin

La fin du livre est consacrée à une bibliographie de qualité et des références web complètes.

A la lecture on se pose des questions sur ses projets en cours, on prends des notes, on vérifie… Le livre aborde des sujets tellement variés qu’il y a forcément quelque chose à apprendre ou réapprendre. Devant la multitude, on passe souvent à côté points qui nous semblent plus ou moins anodins et il est bon de se les remémorer de temps à autre.

Mon seul bémol, des chiffres et références pas toujours à jour. Cela reste un détail puisque les tendances énoncées semblent bonnes, on aurait juste aimé des chiffres plus justes, de manière à être plus crédible si on doit les présenter à un client pour étayer un sujet.

Chapitrage

Le livre est découpé en 5 chapitres :

• Contenu
  (Écriture, utilité, crédibilité…)
• Navigation
  (Facilité de navigation, qualité de la recherche, liens…)
• Design graphique
  (Qualité de la charte graphique, typographie, multimédia…)
• Interactivité
  (Utilisabilité, , convivialité, contact…)
• Aspects techniques et fonctionnels
  (Performance, qualité du code, accessibilité, standardisation, sécurisation…)

Photo de Gaetano Palermo d’Expressions.be

Les auteurs

Jean-Marc hardy est consultant et formateur auprès des chefs de projets Internet, enseignant, il est également l’auteur du blog 60questions.net. Il a écrit la première version de ce livre en 2004.

Gaetano Palermo, diplômé en journalisme, est responsable de projets e-business, consultant, formateur, créateur de contenu et expert en ergonomie web, vous pouvez le retrouver sur son blog Expression.be. Il participe à la rédaction de ce livre depuis la seconde édition.

Interview des auteurs

Afin de mieux les connaitre, voici trois questions sur leur métier et leur façon de voir le web.

J’en veux un !

• Réussir son blog professionnel
• 200 conseils pratiques, 120 études de cas et 150 repères statistiques
• Broché : 151 pages
• Éditeur : Dunod
• Édition : 3ème (10 mars 2010)
• Collection : Cré@
• Langue : Français
• ISBN-13: 978-2100545650

Pour résumer, ce livre est un condensé de ce qu’il faut connaitre pour faire du web… Exactement la philosophie de mon blog ! la différence tient à l’exhaustivité du livre qui traite vraiment tous les sujets, mais je compte bien rattraper mon retard…

En attendant, Lisez le !

Sur le même thème

• Veille techno Web de A à F (partie 1)
• Livre : Réussir son blog professionnel
  3 exemplaires à gagner !
• Veille techno Web de F à Z (partie 2)
• Internationalisation & localisation
• Livre : HTML5 pour les webdesigners

Ceux qui les utilisent sont convaincus, mais l’optimisation de sites web semble toujours un truc inutile, comme l’accessibilité ou l’ergonomie…
C’est à mon sens une hérésie, et les performances, comme l’accessibilité ou l’ergonomie devraient faire partie des premières réflexion sur la plupart des projets web.

Pour vous sensibiliser à cette technique je vais donc vous présenter quelques outils utiles à sa mise en place.

Photo de Jeff Kubina depuis Flickr

Performance ?

Avant de voir comment faire voyons déjà pourquoi le faire. En deux mots, des performances de votre site web, dépendent la qualité de votre référencement et la qualité de surf de vos visiteurs. Votre rentabilité est donc en lien direct avec la rapidité de votre site.

Avant de songer à changer de serveur, il y a deux points importants à traiter pour améliorer votre site :

• Limiter le poids des données
• Limiter le nombre de données

Les sprites CSS permettent de limiter le nombre de fichiers en les combinant. Cela amène aussi en règle générale à une diminution du poids total des images.

Pour en savoir plus sur l’optimisation :

• Le blog d’Éric Daspet sur les performances
• Le billet de Webaaz sur les performances

Méthode

Pour ce qui et de la technique des sprites, je vous renvoie vers le bon tutoriel de Pompage :

• Tutoriel sur pompage
• Voir les explications sur le blog Performances

Pour l’essentiel, sachez que seules les images qui servent au design de votre site peuvent être utilisées. Les images du contenu ne doivent pas subir ce traitement !

Webwares

Pour une utilisation simplifiée on trouve pas mal d’applications web qui fournissent un outil de génération de sprites. Il suffit de fournir vos images sous forme d’archive, de préciser vos paramètres (alignement, espace entre les image, préfixes css…). Il ne vous reste plus qu’à télécharger votre image et le code CSS associé et à les intégrer dans votre site web.

En voici quelques exemples :

• Le générateur de sprites de Ryan Breen
• CSS Sprites
• Spritegen
• Csssprites

Celui-ci est un peu différent puisqu’il permet de redéfinir le style CSS à partir d’un sprite. Utile si vous faites le sprite vous même ou si vous avez perdu le code CSS !

• Générateur de syles CSS Sprite creator

software

Pour une intégration plus poussée dans votre processus d’intégration, il existe aussi des outils en ligne de commande :

• Css Sprites en Java

Vous pourrez ainsi automatiser cette tâche dans un script. Très utile si vous devez régénérer régulièrement des sprites dans le cadre d’un cycle d’intégration continue par exemple !

Il faut noter que la version Java est sous license Open Source BSD License et la version Python

Conclusion

Des outils indispensables aujourd’hui ! Vous n’aurez plus d’excuses pour ne pas les utiliser !
Et pour plus de résultats, n’oubliez pas de merger et de compresser vos fichiers CSS et de supprimer les méta données de vos images !

Sur le même thème

• Optimiser son site web
• Trouver de belles photos pour son site web
• Bien utiliser les feuilles de style (CSS)
• Les plugins Firefox : Firebug
• Retour d’expérience : Grilles & mise en page

Photo de tochis depuis Flickr

Définitions

Les concepts sont importants à maitriser, je vous invite donc à lire les définitions suivante si besoin.

• Internationalisation
• Localisation

Analyse

Un site multilingue, quel que soit le niveau de complexité, se prévoit en amont du développement lors de la phase d’analyse. C’est une problématique tellement imbriquée dans le code qu’il est contre-productif de vouloir passer un site en plusieurs langues si cela n’a pas été pensé lors de sa conception. C’est d’autant plus dommageable, qu’y penser au préalable n’est pas vraiment plus compliqué et ne coûte bien souvent pas beaucoup plus cher.

Ainsi sans tout prévoir on peut mettre en place les bases d’un travail ultérieur sur le sujet.

Traduction

La traduction, c’est à cela que l’on pense en premier quand on veut que son site soit visible dans d’autres pays. C’est un passage obligé et il ne faut pas le négliger. Quoi de plus désagréable qu’un texte dans un français approximatif. Cela peut être catastrophique en termes d’image et de confiance, surtout sur un site marchand !
La solution idéale est de confier le projet à un traducteur professionnel, de préférence dont la langue natale est la langue cible. Il sera ainsi plus à même de connaître les spécificités de la langue.

Sur un projet d’envergure, évitez autant que possible d’autres solutions bancales qui n’apporteraient finalement pas grand chose à l’internaute visé, ou faîtes le en connaissance de cause et en mesurant les risques encourus.

Dans le cas d’un blog et si vous maitrisez vous même la langue voulue, c’est un excellent exercice. Attention cependant à avoir un niveau suffisant pour que cela ne se retourne pas contre vous.

Domaines & IP du serveur

Un domaine par langue ou zone géographique vous apportera un plus auprès de l’internaute qui se sentira plus proche d’un site de son pays. Il n’aura pas l’impression d’être juste sur une traduction, mais sur un site implanté près de lui.

Pensez aussi à avoir si possible une IP localisée dans la zone correspondante, c’est un plus pour les moteurs de recherches.

Search Engine Optimization

Une bonne internationalisation passe par la prise en compte des techniques de référencement. Les mots clés utilisés ou les urls doivent être dans la langue cible afin de positionner correctement le site sur les moteurs de recherche pour chaque langue.

Urls

Les urls réécrites dans la langue de l’utilisateur permettent d’être mieux référencé et sont plus simple à lire ou écrire pour l’internaute. Si il voit l’adresse sur un autre site ou dans le contenu d’un mail, il en comprendra immédiatement le contenu. C’est une solution plus ou moins complexe à mettre en place, mais très efficace.

Mots clés

Les mots clés doivent êtres choisis en concertation avec le traducteur, afin de coller au mieux à la problématique. Là encore, une traduction mot à mot risque de ne pas suffire. Une connaissance du contexte local est un vrai plus.

Régionalisation ou localisation

Pour aller encore plus loin, on peut adapter chaque détail apparemment sans importance, mais qui fera cependant la différence. Il ne vous viendrait pas à l’idée d’écrire la date au format américain sur un site français, ne faites pas le contraire ! Il convient donc de connaitre et respecter chaque culture.

Format des chiffres dates et heures

Chaque continent et chaque culture à des conventions différentes pour les dates et heures, le calendrier ou les unités de mesure. Pour que votre contenu soit compréhensible facilement, votre lecteur doit comprendre de quoi vous parlez sans avoir à faire de conversions. Il faut donc y penser lors de la rédaction du contenu mais aussi dans la mise en page du site, pour convertir et afficher les données à la volée.

Sens de lecture

Là aussi, on voit souvent le problème du point de vue occidental, mais les arabes ou les chinois n’ont historiquement pas les mêmes habitudes que nous. Je n’ai pas eu à régler ces problématiques, mais j’imagine qu’une bonne prise en compte doit demander une charge de travail certaine.

Images et couleurs

D’un pays à l’autre les couleurs sont perçue différemment et si pour nous le rouge signifie ce qui est interdit et le vert ce qui est autorisé, ce n’est pas cas partout. La signalétique à donc besoin d’être adaptée en conséquence.
Pour les images, le problème est le même. Tout les peuples n’ont par exemple pas le même rapport à la nudité, même partielle, ne risquez pas de choquer un internaute par méconnaissance et adaptez les images ou le contenu à sa zone géographique.

Je ne pense pas cependant qu’il faille aller aussi loin que cette multinationale américaine qui a transformé un homme d’origine africaine en européen pure souche entre sa version américaine et son site polonais, mais on entre dans un autre débat…

Particularismes régionaux

Dissociez bien l’extension du nom de domaine pour le pays et la langue ! Certains pays comme la Belgique ayant plusieurs langues officielles, chaque région étant attachée à sa langue. Par ailleurs et pour les mêmes raisons, préférez un affichage de la liste des langues supportées plutôt que des drapeaux qui ne représentent pas des langues mais des pays. Ne brusquez pas les sensibilités de vos visiteurs.

Contenu spécifique

Technique

Bien évidemment il va falloir standardiser au maximum pour être efficace. L’emploi d’un jeu de caractères unicode s’impose pour gérer un maximum de langages.

Mise en place

Les frameworks et les CMS récents implémentent désormais tous, de façon plus ou moins complète des outils pour mettre en place l’internationalisation et la localisation. Penchez vous sur l’existant, d’autres que vous ont réfléchi au problème et le sujet étant complexe, il est ainsi plus facile à appréhender.

Maintenance

Les mises à jour qui découleront d’une version en plusieurs langues sont évidemment plus complexes et plus nombreuses à mettre en œuvre. Côté technique tout doit donc être prévu pour faciliter ce travail afin qu’il ne devienne pas fastidieux.

Conclusion

L’internationalisation et la régionalisation ne laissent aucune place au hasard. C’est un travail de longue haleine qui doit être pris en compte le plus tôt possible, et qui doit être poursuivi en permanence si l’on veut qu’il soit rentable. Si le but est d’être présent sur tout le globe, il est probablement plus simple de gérer des sites complètement indépendant d’une zone à l’autre, quitte à les faire tourner sur la même solution logicielle, mais avec des contenus différents adaptés aux marchés et spécificités locales et bien sûr à l’actualité de la région.

C’est un sujet complexe sur lequel on à encore énormément à apprendre. J’attends vos retours d’expérience avec impatience, surtout si vous travaillez nativement dans une autre langue et que vous internationalisez en français.

Sur le même thème

• Bien gérer ses noms de domaine
• Les générateurs de sprites CSS
• Optimiser l’utilisation d’Eclipse
• Livre : HTML5 pour les webdesigners
• Fournir un webservice et son API

Photo de i_gallagher depuis Flickr

Concept

L’expression « Réinventer la roue » exprime l’idée de ne pas refaire inutilement quelque chose qui a déjà été fait. « Réinventer la roue carrée » y ajoute l’idée d’une réinvention de moindre qualité. Wikipédia fais le point sur ces concepts :

• Réinventer la roue
• Réinventer la roue carrée

Les éléments à charge pour étayer l’expression sont évident et pourtant, dans certains cas ce n’est pas si évident…

Le pour

Donc le contre réinventer la roue.

Pour ce qui est des concepts élémentaires qui font leurs preuves depuis toujours, parfois avant même l’histoire de l’informatique, la question ne se pose souvent même pas. Sur certains problèmes simples, on connait la meilleure solution de traiter les cas, alors pourquoi chercher à faire autrement.

Déjà éprouvés

On a tous étés confrontés un jour à un code un peu complexe que l’on a fini par simplifier à l’extrême en découvrant une solution simple et efficace sur Internet mais à laquelle on avait pas pensé.

Internet favorise l’échange de savoirs de façon exponentielle. Tout internaute un peu curieux peu apprendre rapidement sur le sujet de son choix, on peut ainsi facilement trouver et utiliser une bibliothèque ou un framework et gagner un temps non négligeable en évitant de réécrire l’essentiel. Aujourd’hui très peu de projets partent de zéro, on s’appuie toujours sur une couche existante.

Un code optimisé et fiable c’est ce que tout bon développeur recherche alors si on vous le propose tout prêt, pourquoi hésiter ? Ne risquez pas de faire pire, réutilisez !

Gain de temps

Ce serait donc une perte de temps évidente de chercher à réinventer ce que d’autres ont développé. D’autant que bien souvent les projets communautaires sont d’une grande qualité et la somme des compétences techniques de leurs auteurs est bien plus grande que la votre ou celle de votre équipe. On ne peut pas être spécialiste dans tout les domaines ! Faites confiance à d’autres équipes, vous gagnerez en temps de développement et même sur la maintenance, les évolutions et corrections de bugs ne seront pas de votre ressort !

Le temps gagné vous permettra peut être de publier votre propre code et d’en faire gagner à quelqu’un d’autre.

Le contre

Donc le pour réinventer la roue.

Quel que soit l’outil ou le concept, on pense souvent que tout est déjà inventé et pourtant de nouvelles idées et de nouveaux produits voient le jour quotidiennement et ils paraissent tellement évidents qu’on se demande pourquoi on y à pas pensé soi-même un peu plus tôt… Comment ses idées ont elles germé ? Bien souvent en envisageant un problème sous un autre angle, en se posant une question de manière différente. Bien des inventions ne sont que la réunion de plusieurs.

Comprendre les concepts & les adapter à d’autres inventions

Avoir une approche différente est essentiel. Il faut comprendre le fonctionnement de la roue pour pouvoir l’améliorer ! Utiliser une bibliothèque ou un framework c’est bien, mais en comprendre le fonctionnement c’est encore mieux. Quand vous en maitriserez le fonctionnement, quand leur conception vous semblera claire, vous pourrez les réutiliser efficacement dans d’autres cas.

Votre y gagnerez en compétence et en efficacité.

Il y a quelques années, avant l’arrivée des frameworks PHP, j’ai développé ma propre solution. Cela m’a permis de gagner beaucoup de temps en mutualisant certains développement entre plusieurs projets. J’ai gagné en compétence car je souhaitais toujours trouver la meilleure solution à un problème donné. Aujourd’hui j’appréhende d’autant mieux les outils que j’utilise même si je ne les ai pas écrits moi même.

Nouvelles idées ou fonctionnalités

Re-développer un outil ou réfléchir à un concept avec un œil neuf vous apportera peut être une idée de génie. Le petit truc auquel personne n’avait pensé, la fonctionnalité évidente qui donnera une longueur d’avance à votre projet. Un truc évident, après coup, mais qui nécessitait un certain point de vue, certaines connaissances, tout un ensemble de choses que personne n’avait visiblement eues avant vous.

Usage spécifique & optimisation des performances

Dans certains cas, il faut savoir si la roue qu’on nous propose nous convient vraiment, et si on n’ a pas besoin de la modifier ou de la réinventer pour répondre de manière plus précise à son besoin. Pourquoi utiliser un outil avec des tas d’options si votre besoin est vraiment basique. L’analyse de l’outil et sa réécriture permettent de monter en compétence sur le sujet et d’avoir un produit répondant uniquement à votre besoin et du coup plus performant.

Le contraire est vrai aussi, et si un outil ne propose que 90% de vos besoins, améliorez le et proposez les améliorations à la communauté !

Conclusion

Réinventer le roue peut s’avérer utile pour innover, et c’est en tout cas un moyen formateur pour qui veut apprendre d’autres outils ou concept pour les faire évoluer ou en comprendre l’essence et l’adapter à d’autres cas. N’ayez plus peur de réinventer la roue, mais faîtes le en connaissance de causes et pour de bonnes raisons

Et vous alors ? Réinventez vous la roue ? Est ce pour de bonnes raisons ? Que pensez vous des miennes ?

En question subsidiaire, j’aimerai savoir d’ou vient l’expression, je n’ai pas trouvé d’information sur son origine.

Sur le même thème

• Les plugins Firefox : FoxyProxy
• Bien utiliser Zend Framework
• Bien définir son projet de site web
• Les plugins Firefox : Colorzilla
• Comment apprendre le développement web ?

Lors de la refonte d’un site, le prestataire à tendance à vouloir tout refaire sous prétexte que l’existant est inadapté, c’est peut être vrai, et d’ailleurs très souvent le cas, mais dans ce cas il faut réfléchir et travailler pour que cela ne se reproduise pas systématiquement à chaque version. Si le projet est bien pensé, une refonte graphique et quelques développements peuvent suffire la plupart du temps, à moins bien sûr que le fonctionnel change du tout au tout ou qu’un autre paramètre important ai changé de manière significative.

Comment prévoir et intégrer les évolutions du projet ? Quelles questions se poser ? Quelles sont les erreurs à ne pas faire ? Voilà tout l’enjeu de cette réflexion.

Photo de slinky2000 depuis Flickr

Modularité

Avec les moyens actuels, et le développement en couche, on peut facilement changer une partie d’un projet sans toucher au reste. Le principe MVC permet par exemple de changer complètement l’affichage de votre site sans toucher à la partie métier. On peut ainsi cloisonner le projet, les différentes parties travaillant chacune de leur coté, mais ensemble.

Il faut pour cela réfléchir à certains points en amont du projet. Voyons les questions à se poser le plus tôt possible.

Volumétrie

Le choix d’un site marchand est évident si vous vous lancez dans la vente, mais si vous commencez avec de faibles volumes, un site vitrine est peut être plus approprié, votre projet à 30 000 € peut attendre… Tout dépends de vos ambitions !

Et côté hébergement, suivants vos besoins actuels et à moyenne échéance, en terme de ressources processeur ou de bande passante, les extensions nécessaires, le prix… Il faudra faire le tri et trouver un hébergement au meilleur rapport qualité prix, mais facilement évolutif pour pouvoir migrer vers une offre supérieure simplement.

Je vous invite à voir l’article de Webaaz sur l’hébergement web.

Prévoyez donc de dimensionner votre projet en fonction de vos besoins à court terme et des évolutions à venir.

Fonctionnalités

On ne peut bien évidemment pas aborder ici toutes les problématiques fonctionnelles, voyons donc en deux points qui nous serviront d’exemple, comment envisager ces questions.

Public visé

En fonction de votre cible, vous ne ferez pas le même site web. Le collaboratif c’est plutôt orienté vers la génération X et la génération Xgénération Y, alors si vous vous adressez à un public plus âgé, faites plus simple, avec une ergonomie adaptée, des boutons plus gros par exemple…

Pensez tout de même à toujours garder votre site accessible à tous pour ne pas vous couper d’une partie de la population !

Multilinguisme

Sur le web votre site est accessible par tout le monde. Même les internautes auxquels vous n’avez pas pensé. Ils ont aussi le droit d’y venir, et même de consommer ! Vous n’allez tout de même pas vous priver de ces clients sous prétexte de ne pas parler la même langue ?

Bon, peut être que dans un premier temps vous ne pensez pas à cela et que votre marché est francophone, mais vous avez déjà pensé à vous étendre par la suite, alors dites le ! Intégrer plusieurs langues dans un site existant est très couteux, et oblige à revoir le site en profondeur, alors que développer un site multilingue n’est pas beaucoup plus compliqué qu’un site en une seule langue.

Alors à moins d’être sur un périmètre géographique très restreint, prévoyez ! Voyez grand !

Technologie

Je vais passer pour quelqu’un d’arriéré, mais non un site web statique n’est pas dépassé ! Même si aujourd’hui les besoins évoluent et que la mode est au web social, au web 2.0, à l’interactivité, posez vous la question : Ai-je besoin de tout cela ?

Si votre site ne nécessite que peu de pages et peu de mises à jour, un site vitrine fera parfaitement l’affaire. Pourquoi mettre une usine à gaz pour si peu de besoins ?

Et même si votre projet doit être dynamique, les fonctionnalités qui manquent à votre CMS ou à votre blog ne peuvent elles pas être juste des pages statiques en plus ?

Au final, des pages statiques, ce n’est pas forcément moins évolutif qu’un code dynamique.

Cahier des charges

Pour réunir toutes ces réflexions, et le résultat de toutes ces questions, un cahier des charges s’impose. Fonctionnel dans un premier temps pour définir clairement les besoins. Technique ensuite pour expliquer les moyens de répondre à la demande.

Fonctionnel

Vous pourrez y expliquer vos besoins précis en fonctionnalités en expliquant les règles métier spécifiques à votre entreprise.

Technique

Il sert à définir les solutions techniques retenues et la manière de les mettre en œuvre. Le développeur s’appuie dessus pour développer votre site web. Tout y est expliqué et en théorie, il y trouve toutes les réponses à ses questions.

Evolutivité

Coté évolutivité, il y a du boulot ! Il va falloir penser à ce dont vous aller avoir besoin, sans pour autant penser à des fonctionnalités que vous n’êtes pas sûrs d’utiliser, ce qui serait totalement contre productif. Si vous êtes une PME, n’imaginez pas que votre site vitrine puisse se transformer en site marchand ou en réseau social, mais pensez que vous aurez besoin de nouvelles pages pour les nouvelles agences du groupe par exemple.

Vous avez besoin de donner accès à votre catalogue à d’autres application ? Développez un webservice qui pourra resservir et évoluer.

Mise en œuvre

Je le fais moi même ou je le fais faire ?

La question ne se pose bien évidemment que pour un site perso, ou un site pro très simple genre site vitrine. Pour de plus grosses structures, c’est une question de crédibilité (encore que ce ne soit pas le cas pour tout le monde).

Pour un site plus conséquent, le temps, les compétences nécessaires et le résultat attendu ne vous laisseront bien évidemment pas le choix.

Bien sûr faire soi même son site web demande des compétences, mais pour un petit projet et pour peu que cela vous intéresse c’est tout à fait possible. Différentes formations abordent le sujet de façon plus ou moins approfondie.

L’article de Webaaz sur les formations web vous en apprendra plus sur le sujet.

Conclusion

Le but est de penser à tout ce qui pourrait arriver, et supprimer finalement tout ce qui n’arrivera pas. Quand on a enlevé tout le superflu, il ne reste que l’essentiel, et c’est ce dont vous avez besoin !

Vos besoins évolueront probablement, et lors de la prochaine refonte vous vous reposerez les mêmes questions, et vous n’aurez sûrement pas les mêmes réponses. Votre prestataire Internet vous dira peut être qu’il faut tout refaire, et il aura peut être raison, mais l’existant pourra resservir en partie grâce à la modularité ! C’est déjà ca de gagné !

Mise à jour

Le sujet est un peu vaste pour être abordé de façon complète dans un seul article. Je complèterai donc cet article et j’aborderai des sujets connexes de manière plus précise par la suite, en fonction de vos retours.

A vos commentaires !

Sur le même thème

• Réinventer la roue, ou pas ?
• Les plugins Firefox : XRefresh
• Les plugins Firefox : Colorzilla
• MySQL GUI Tools
• Bien utiliser Zend Framework