Quels sont les « entrants » nécessaires pour lancer un projet front-end ?

Derrière cette simple question, il s’agit de faciliter le travail des chefs de projets, mais aussi de tous les corps de métiers qui sont amenés à travailler avec nous autres intégrateurs.

Après avoir réuni quelques éléments de réponse personnels, j’ai posé cette question sur Twitter afin d’obtenir un regard extérieur (encore merci aux nombreux participants). J’ai dû faire des choix, pour en limiter la taille et aller à ce qui me semble essentiel ; mais même si cette checklist n’est pas parfaite, vous avez là une base de travail que j’espère néanmoins très complète.

Notre métier est fait de choix techniques : il nous faut des contextes précis pour y apporter des réponses adaptées. Cette liste permet de mieux les définir.

Bloquant

Informations fournies par le chef de projet

Contexte projets précis. (Qui est le client ? Y a-t-il un site existant ? Quels seront les intervenants sur le projet ? Quel est le budget ? Quelle cible ? Quelle durée de développement ? Etc.)

C’est important pour éviter de faire de la sur-qualité, pour comprendre les enjeux, pour adapter les contraintes ou pour se sentir impliqué…

Informations fournies par la partie design

Maquettes graphiques validées. (Avec éventuellement des prototypes et/ou des wireframes.)

Les maquettes graphiques permettent de se projeter avant de lancer les phases plus techniques de réalisation. C’est une manière de simuler le résultat final sans engager tout le processus.
Si les maquettes ne sont pas validées, le processus sera déjà engagé et les modifications techniques se révèleront plus lourdes.

Sources des polices non web utilisées.

Les polices sont parfois payantes et doivent également être testées avant de les adopter. Elles sont fournies normalement pour un usage « web » clefs en main.
Si ce n’est pas le cas, il faudra se pencher sur les problématiques de licence et de conversion, ce qui demande plus de temps et de nombreux aller-retours.

Animations complexes ? Préciser les déroulements et les timings.

Les animations complexes demandent bien souvent une structure et un code très spécifiques. Ainsi, il faut définir très tôt leurs comportements car il sera très difficile d’en changer en cours de route.

Liste des formats et ratios des images contribuées.

Les images contribuées ou issues d’une base de donnée existante seront plus difficilement déclinables en différents formats, et encore moins en différents ratios. Il est important d’identifier quels seront les formats courants pour faciliter le travail de développement en aval et s’assurer de la bonne homogénéité de l’ensemble.

Planche de composants graphique avec états survolés, activés, désactivés ; palette de couleurs…

Même si les maquettes sont statiques dans un premier temps et aident le client à se projeter, elles servent ensuite de référence pour les intégrateurs. De nombreux états et comportements doivent alors être définis précisément pour bien s’entendre sur le résultat attendu.

Informations fournies par le client

Cible navigateurs. (Bureau, tablettes et mobiles. Indiquer s’il n’est pas possible de mettre en place une dégradation élégante et une amélioration progressive.)

Les choix techniques associés à l’intégration des maquettes se feront en fonction du parc navigateur défini. Plus ce parc est moderne, plus des techniques avancées pourront être mises en place, au profit d’une bonne maintenabilité et de meilleures performances notamment.

Niveau d’accessibilité demandé ? (En précisant si ça entre dans le cadre d’une labellisation.)

Bien que les bonnes pratiques du métier soient généralement appliquées, une contrainte forte en accessibilité changera l’approche technique des choses, il est important de le prévoir (avant même la partie design, cette contrainte va impacter tout les intervenants du projet).

Multilingue ? (En précisant s’il y a du RTL ou des langues asiatiques le cas échéant.)

Là encore, bien qu’il soit d’usage de toujours anticiper sur la longueur des contenus, il sera intéressant d’y porter une attention particulière sur les sites multilingue. Dans le cadre des intégrations RTL ou dans des langues asiatiques, de nouvelles contraintes viennent s’ajouter sur la conception ; mieux vaut anticiper les choses.
Quelle méthode de positionnement préférer quand la maquette doit pouvoir s’inverser verticalement, ou quelles polices utiliser pour les langues asiatiques ?

HiDPI ?

Intégrer pour des écrans à haute densité de pixels demande des sources adaptées (soit des maquettes entières, soit des planches de composants). Il faut également faire des choix entre images matricielles et images vectorielles. Les techniques employées seront ensuite très différentes.

RWD ? (Indiquer si le site sera fluide et/ou s’il y a des paliers.)

Évidement, un travail plus conséquent est à prévoir quand le site doit s’adapter à une grande variété de tailles d‘écrans.
D’un point de vue technique, penser une interface en fluide ou avec des paliers pourra complètement changer l’approche technique. Il est préférable d’avoir cette information dès le départ.

Version imprimée à prévoir ?

Cette partie peut impacter légèrement les plannings et est pourtant souvent oubliée. Les difficultés techniques associées imposent parfois de bien échanger sur le sujet si la demande est précise.

Informations fournies par le client ou la partie développement

From scratch ? (Ou sinon préciser le contexte de l’existant.)

Il sera toujours plus facile de partir sur des bases saines. Hériter d’un existant demande de bien le définir pour mieux l’appréhender.

Contraintes de production ? (Par exemple des bibliothèques imposées, des plugins ou une architecture particulière…)

Il peut arriver que des clients imposent l’utilisation d’outils spécifiques. Il faudra alors maîtriser cette contrainte supplémentaire et sans doute adapter ses processus en fonction.

Contraintes projet spécifiques ? (Par exemple les performances…)

Définir un (ou des) axe(s) de travail permettra de savoir où porter son attention et à être en phase avec les attentes du client.

Informations fournies par la partie développement

Contraintes en développement ? (Par exemple un CMS qui demande du code spécifique, un framework… Fournir les templates adaptés si besoin.)

Il n’est pas toujours possible pendant la phase de développement d’adapter certaines structures imposées par les outils. Aussi, si cela est possible, il est intéressant de communiquer la contrainte aux intégrateurs, qui tacheront alors de contourner le problème différemment.

Format d’échange des données avec les développeurs le cas échéant.

Il sera nécessaire de bien s’entendre sur les formats de données échangées avec les développeurs, pour là encore gagner du temps et éviter des incompréhensions.

Informations fournies par le client ou la partie SEO

Contraintes SEO ? (Par exemple la présence d’un sitemap ou d’une hiérarchisation particulière de l’information, mise en place de microformats ou microdata…)

Il arrive que des contraintes SEO ne soient pas en adéquation avec les bonnes pratiques du métier. Il faut pouvoir l’anticiper pour trouver un compromis, ou simplement ne pas oublier de coder la demande.

Utile

Informations fournies par la partie design

Grille verticale et/ou horizontale.

Intégrer avec des grilles permet d’assurer un meilleur respect du design, tout en facilitant l’étape d’intégration.
Les grilles permettent aussi d’assurer facilement une cohérence graphique tout au long de la vie du projet.

Échelles typographiques.

Les échelles typographiques peuvent être automatisées au niveau code, cette donnée doit être partagée pour qu’elle soit reprise.

Informations fournies par le client ou par la partie design

Contenus types.

Les véritables contenus permettent de mieux appréhender les comportements des maquettes. Il est aussi plus facile d’en contrôler la bonne lisibilité et également d’y apporter les détails sémantiques et micro-typographiques nécessaires.

Informations fournies par le client

Statistiques de navigation du site existant s’il en existe.

Avec ses statistiques, le parc navigateur défini plus haut peut être ajusté plus finement. Les statistiques apportent également un axe supplémentaire sur les questions de contexte projet.

Points d’attention

Informations fournies par la partie design

• Design des messages d’erreurs sur les interactions (formulaires, AJAX…)
• Design des pages d’erreurs. (Erreur 404…)
• Design des e-mails éventuels ? (Avec des contraintes et des besoins dédiés.)
• Design de la favicon et de ses variantes mobiles.
• Design pour les chargements dynamiques (les loaders).
• Design du message relatif aux cookies.
• Design de la page mentions légales si nécessaire.

Ces points sont très souvent oubliés lors de la phase de design. Pourtant ils sont presque toujours nécessaires, et mènent inévitablement à un nouvelle itération.

À vous

Peut-être serait-il intéressant de voir cette procédure copiée à d’autres corps de métiers ? Peut-être qu’il s’agit là d’un travers au travail en silos ? Peut-être qu’il manque quelque chose d’essentiel à cette liste ?

Je serais très heureux de lire vos commentaires.

• Cette cheklist est également disponible sur Trello.
• Et également au format markdown.

Le dernier billet publié sur Les Intégristes parlait d’humilité et de bienveillance à l’égard de nos pairs.

Être bienveillant implique de soutenir nos collègues, d’être indulgent à leur égard, mais cela n’exclut pas d’avoir le courage de leur parler avec honnêteté en cas de problème.

C’est en écoutant des confrères et consœurs travailleurs du web me parler de leurs frustrations au quotidien, qui par email, qui sur Twitter, qui pendant Paris Web, que j’ai eu envie d’écrire sur la relation singulière entre intégrateurs et chefs de projet – une relation ô combien essentielle, sur laquelle on trouve pourtant bien peu de littérature.

Derrière ce billet, il y a un constat : en 2014, j’ai été témoin d’une irritation sourde et croissante chez mes pairs, irritation souvent provoquée par des gestions de projet catastrophiques.

À l’incompatibilité supposée entre intégrateurs et designers a succédé, semble-t-il, la lassitude de certains d’entre nous à l’égard de certains chefs de projet avec qui nous collaborons au quotidien. C’est un ressenti que j’ai perçu de façon assez globale, mais que j’ai trouvé particulièrement exacerbé auprès de mes confrères et consœurs travaillant en agence.

Certes, il est toujours plus facile de voir la paille dans l’œil du voisin que la poutre qui est dans le sien.

J’ai conscience que pointer du doigt les mauvaises habitudes de mes pairs est, sinon politiquement incorrect, du moins délicat. C’est pourquoi je me suis essayée à une forme d’écriture plus légère que d’habitude, sous forme de conte de Noël, ceci afin de provoquer une prise de recul salvatrice.

J’espère de tout cœur que cette prise de risque donnera lieu à des débats enrichissants pour nous tous.

Il était une fois…

Il était une fois, dans un pays très, très lointain, une petite agence web.

Cette petite agence web réussissait toujours à décrocher les projets les plus excitants et les plus valorisants.

Ses clients étaient tous éduqués, sages et riches.

Pour ne rien gâcher, ses locaux rutilants et faciles d’accès se trouvaient à deux pas de la meilleure boulangerie du pays.

C’est dans cette petite agence web que travaillaient main dans la main les Ergonomes, les Designers, les Intégrateurs, les Développeurs, les Commerciaux et les Managers :

• Les Ergonomes avaient toujours le budget nécessaire pour réaliser des tests utilisateurs ;
• Les Designers bénéficiaient à chaque fois d’au moins huit jours pour préparer les avant-ventes ;
• Les Intégrateurs convainquaient à tous les coups leurs interlocuteurs des bienfaits de l’accessibilité ;
• Les Développeurs avaient toujours à leur portée des spécifications complètes et finement rédigées ;
• Les Managers suivaient les plannings à la perfection. Réactifs, c’était des forces positives sur lesquelles on pouvait compter en cas de coup dur ;
• Les Commerciaux quant à eux réussissaient toujours à négocier plus de charges pour que les Ergonomes, les Designers, les Intégrateurs et les Développeurs puissent travailler sereinement, sans pression.

C’est aussi dans cette petite agence qu’officiaient des professionnels réputés : les Chefs de projet idéaux. Ceux-ci orchestraient tous les projets de la petite agence avec flair et doigté.

Que soient narrés aujourd’hui quelques-uns de leurs hauts faits, à travers le prisme de leurs interactions constantes avec les Intégristes Intégrateurs.

Chiffrage et planification

Avant toute chose, les Chefs de projet idéaux pensaient à mettre les Intégrateurs dans la boucle, non seulement pour valider la faisabilité du projet côté front-end et pour macro-chiffrer la charge en intégration, mais également pour lister avec eux tous les éléments dont ils auraient besoin pour commencer à travailler sereinement.

Quand ils savaient qu’un apprenti prendrait part à un projet complexe, les Chefs de projet idéaux veillaient à solliciter un Intégrateur senior afin d’estimer la charge en fonction de ce paramètre.

Les Chefs de projet idéaux faisaient tout leur possible pour éviter que les Intégrateurs soient envoyés du jour au lendemain dans une régie obscure. En effet, les Intégrateurs travaillaient mieux dans un contexte connu. Les régies sont bien souvent synonymes, au mieux, de webmastering désagréable, au pire, de gestion d’urgence, là où une organisation rigoureuse devrait pouvoir éviter ça.

Lorsque Ergonomes et Designers prenaient du retard dans la conception du projet, les Chefs de projet idéaux rassuraient les Intégrateurs en leur confirmant que la date butoir glissait également pour eux.

Enfin, les Chefs de projet idéaux étaient bien organisés, et briefaient les Intégrateurs avant qu’ils ne commencent à travailler.

Qualité du projet

Les Chefs de projet idéaux avaient le cran de parler avec franchise des diverses contraintes à leurs Clients. Ils savaient que, s’ils y manquaient, le projet hériterait d’exigences supplémentaires pour le moins coûteuses.

Les Chefs de projet idéaux avaient à cœur la qualité des projets qui passaient entre leurs mains. Ils ne demandaient pas aux Intégrateurs de mettre en place des mauvaises pratiques par simple peur de devoir dire « non » aux Clients. Par exemple, les Chefs de projet idéaux savaient qu’il était important de former les contributeurs au sous-titrage des vidéos.

Car, oui, les Chefs de projet idéaux accordaient de l’importance à l’accessibilité. Ils savaient que l’accessibilité du web ne concernaient pas uniquement les personnes en situation de handicap, mais qu’elle bénéficiait à tous, et que, si elle était prévue dès la genèse du projet, il serait plus facile de la mettre en œuvre.

En début de projet, les Chefs de projet idéaux prenaient soin d’annoncer aux Intégrateurs que le site devait être responsive, multilingue, optimisé « retina » et/ou compatible avec Internet Explorer 6.

Et, lorsque les Intégrateurs leur demandaient la liste complète des navigateurs avec lesquels le projet devait être compatible, les Chefs de projet idéaux la leur fournissaient facilement.

Les Chefs de projet idéaux prenaient soin de rassembler tous les entrants nécessaires à la bonne exécution des tâches, notamment les maquettes graphiques validées.

Tout affables qu’ils étaient, les Chefs de projet idéaux savaient argumenter face aux demandes parfois surprenantes des Clients.

Recette et maintenance

Les Chefs de projet idéaux apprirent un jour que le Chef de projet d’une autre petite agence web avait recetté un site 48 heures à peine avant la livraison, alors qu’il avait eu plusieurs mois pour le faire au fil de l’eau. Quand ils entendirent cela, les Chefs de projet idéaux éclatèrent d’un rire tonitruant mais noble, que l’on entendit jusqu’au Mont Fuji et au-delà.

Les Chefs de projet idéaux connaissaient très bien la différence entre ce qui relevait du design, du front-end et du back-end. Ils savaient aussi identifier les zones contribuables d’un site. Ainsi, les Chefs de projet idéaux étaient toujours à l’aise pour qualifier les tickets qui passaient entre leurs mains.

De même, les Chefs de projet idéaux assignaient un nombre raisonnable de tickets à une même personne, prenant en compte son degré de connaissance du projet et la difficulté des tâches attendues.

Les Chefs de projet idéaux évitaient aussi d’assigner aux Intégrateurs un ticket concernant, au choix :

• un bug déjà soulevé à plusieurs reprises,
• une anomalie repérée dans un navigateur hors périmètre,
• un problème de contribution,
• une erreur de traduction,
• une demande d’évolution,
• ou encore une majuscule manquante dans un texte, et ce sur 15 gabarits.

Par ailleurs, dans le cadre d’un projet responsive, les Chefs de projet idéaux prenaient soin de rédiger un rapport de bug complet, qui précisait la résolution et le périphérique sur lesquels apparaissaient les anomalies.

Diplomatie et confiance

Les Chefs de projet idéaux gardaient la tête froide. Ils savaient que leur rôle est essentiel pour mener les projets à bien, en particulier pour synchroniser les efforts des différents corps de métiers, et pour arbitrer en cas d’imprévu.

Si, d’aventure, un Intégrateur leur faisait part de ses inquiétudes, les Chefs de projet idéaux prenaient le temps de lui répondre, soit pour le rassurer, soit pour lui montrer qu’ils avaient bien pris en compte ses recommandations ou ses alertes.

Les Chefs de projet idéaux faisaient confiance aux équipes techniques et graphiques. Ils communiquaient suffisamment au quotidien pour que les premiers ne ressentent pas le besoin de devoir soumettre les autres à la question, jour après jour, pour savoir où ils en étaient.

Les Chefs de projet idéaux avaient la même considération pour HTML et CSS que pour n’importe quelle autre technologie web. Ils savaient que ces langages en apparence simples cachent des problématiques complexes.

Après une mise en production, les Chefs de projet idéaux citaient et remerciaient, dans les communications associées, tous les collègues ayant pris part au projet.

Lorsque les Intégrateurs terminaient un projet plus tôt que prévu, les Chefs de projet les incitaient à peaufiner le résultat, ou à rédiger un retour d’expérience lorsque le sujet était intéressant, ceci afin d’améliorer la qualité et de favoriser la capitalisation des connaissances.

Les Chefs de projet idéaux savaient créer un esprit d’équipe stimulant pour que chacun puisse, en toute confiance, donner le meilleur de lui-même.

Enfin, les Chefs de projet idéaux considéraient les contraintes de chaque intervenant avec impartialité. Ils étaient attentifs aux besoins de chacun, et savaient faire preuve d’écoute.

Épilogue

Le monde du travail n’est pas un conte de fées.

Derrière sa forme humoristique, ce billet a pour but d’attirer l’attention sur les éléments stratégiques d’une collaboration efficace entre chefs de projet et intégrateurs.

Les chefs de projet ont une grande part de responsabilité dans le succès (ou l’échec) des projets qu’ils gèrent, mais tout ne repose pas sur leurs épaules. Ils font souvent face à des clients qui n’y connaissent rien, persuadés que créer des sites web est facile et que ça ne coûte pas un rond.

Les chefs de projet doivent souvent réaliser un nombre de tâches indéfinies, qui fluctuent en fonction du milieu dans lequel ils évoluent (agence, annonceur) et surtout du client.

Quant à nous, nous ne sommes pas à la place de nos collègues. Nous ne percevons leur travail qu’à travers nos propres problématiques métier, notre sensibilité ainsi que nos a priori, parfois influencés par les tensions passagères que provoquent parfois les projets ambitieux.

C’est pourquoi nous manquons souvent de recul pour comprendre les contraintes particulières auxquelles les chefs de projet font face, ainsi que les décisions qu’ils sont amenés à prendre, d’autant plus lorsque la communication entre eux et nous est insuffisante.

Ensemble, il est sans doute possible d’améliorer les choses.

En tant qu’intégrateurs, nous avons souvent l’occasion de partager notre expérience professionnelle, que ça soit par tweet, par blog ou par conférence interposés.

Nous participons à l’effort collectif de documentation et de communication, peut-être parce que l’intégration web est toujours, fin 2014, une discipline mouvante, difficile à aborder et à définir.

Donner à voir notre quotidien professionnel fournit – espérons-le – des clés à nos interlocuteurs pour mieux comprendre notre métier et ses particularités.

Or, on n’entend que trop rarement les chefs de projet parler de leur métier et de leurs contraintes spécifiques, alors qu’il s’agit d’un métier tout aussi singulier et stratégique.

Une gestion de projet de qualité est cruciale à la réussite des projets web dont nous partageons la responsabilité et, pourtant, il me semble que les chefs de projet communiquent encore assez peu sur le web.

Les chefs de projet pourraient par exemple donner davantage à voir leur quotidien, leurs méthodes, leurs outils et leurs contraintes, quel que soit leur nombre d’années d’expérience, leur statut ou le type de structure pour laquelle ils travaillent, afin qu’eux et nous puissions mieux travailler ensemble.

J’adorerais aussi lire des retours d’expérience rédigés à quatre mains, par un chef de projet et par un intégrateur, tout comme j’adorerais les voir sur scène ensemble pour nous raconter comment ils ont réussi, jour après jour, à améliorer leur collaboration.

Mais cette collaboration renouvelée pourrait sans doute prendre d’autres formes encore…

Maintenant, c’est à vous : connaissez-vous un∙e Chef de projet idéal∙e ? Quelles sont les caractéristiques de vos chefs de projet préférés ? Racontez-moi une belle histoire, soit dans un commentaire, soit sur Twitter, en mentionnant @lesintegristes.

Et, d’avance, belles fêtes de fin d’année à tous !

Merci à Anne, Corinne, Damien, Delphine, Élodie, Éric, Florian, Fred, JP, Julien, Matthieu, Mehdi, Olivier, Pierre, Samuel et Vincent pour leur relecture et leurs conseils avisés.

Et merci à ma maman, Claire Guillaumet, pour ses illustrations.

Depuis le compte du client, quand tu cliques sur telle partie, une phrase en hollandais se transforme en norvégien.

(NDR : Se transforme ?)

Quand on clique sur tel bouton, un message d’erreur est censé apparaitre, là il n’apparait pas.

(NDR : quel message ?)

Apparemment il y un problème sur telle page, je pense qu’il doit manquer un morceau de JS […]

(NDR : « apparemment », « je pense »)

Telle page est cassée sur tous les navigateurs.

Le montant apparaissant sur telle page pour le produit est complètement bidon, le montant total est ok.

(NDR : bidon, hum… »)

Le site est instable sur Internet Explorer, pouvez-vous regardez ? C’est assez problématique.

(NDR : oui, mais encore ?)

Quand on clique sur le carousel, ça donne le tournis, vous pouvez faire quelque chose ?

Laisse tomber, le temps de faire le screenshot, le bug a disparu.

La palme revenant à une remontée d’un bug critique de fonctionnement d’ajout au panier d’un site non identifié (qui s’avèrera être finalement en phase de développement…)

Qu’est-ce qu’il ressort de tous ces exemples ?

1. La description du bug est floue et imprécise.
2. Le rapport a été fait dans la précipitation.
3. Le demandeur ne s’est pas attardé sur le sujet et la plupart du temps se fait le relais du client sans plus d’analyse.
4. Les étapes pour reproduire le bug ne sont pas indiquées.
5. Sur quelle plateforme ? Quel navigateur ? Quelle version ? Où ? Comment ? La plupart du temps on n’en sait rien. Pour le dernier exemple on ne sait pas quel site est concerné.

Les conséquences pour l’intégrateur ou le développeur sont claires : en plus de devoir corriger le bug, il devra la plupart du temps faire un premier travail d’enquête, essayer de comprendre la syntaxe approximative des rédacteurs et s’assurer de la reproductibilité ou de la réalité du bug. Combien d’échanges du type :

• Non moi j’ai rien, tout fonctionne correctement
• Bah, chez moi j’ai toujours le problème
• T’es sur ? c’est quelle version de navigateur ?
• etc.

Comment éviter tout ça ?

Simplement en suivant quelques règles :

1. Vider le cache du navigateur avant toute chose.
2. S’assurer de la réalité du bug.
3. Prendre 10 à 30 minutes pour faire un raport de bugs correct.
4. Soigner la rédaction. Inutile d’utiliser du pseudo-langage technique ou marketing qui la plupart du temps n’est compris que du demandeur.
   Mettez vous d’accord sur un glossaire qui facilitera les échanges. Doit on dire select, droplist, dop-down pour une liste déroulante ?
5. Rester factuel : « j’ai constaté… » action/réaction.
6. Si vous devez travailler avec des développeurs et/ou intégrateurs, vous devez avoir un minimum de connaissances : html, css, php, ça doit vous
   parler un minimum. Rien ne vous empêche d’être curieux ou de discuter avec le technicien qui se fera un plaisir de vous expliquer.
7. Reproduire le bug et en décrire toutes les étapes avec précision ainsi que sa fréquence.
8. Indiquez toutes les informations qui seront utiles pour le constat du bug : version du navigateur, plateforme, lien pour accéder de la page concernée, screenshot si nécessaire.
9. Indiquer la sévérité du bug, inutile de mettre tout en urgent, ce ne sera pas traité plus rapidement et vous risquez de voir des bugs mineurs,
   résolus avant des bugs bloquant des fonctionnalités plus importantes sur le site.
10. Relire le rapport avant de l’envoyer (soigner l’orthographe et la rédaction).

Il n’est pas interdit également de se déplacer et de faire une démonstration en direct du problème ce qui peut s’avérer quelques fois plus rapide que des échanges interminables de mails ou de commentaires. Vous pouvez aussi faire une petite vidéo des actions provoquant le bug, certains logiciels comme CamStudio (au hasard) permettent de capturer les mouvements effectués sur votre écran d’ordinateur.

Quelques articles sur le sujet :

Apprendre à rapporter un bogue
Les bugs mystiques
Comment signaler efficacement un bug

Il existe de nombreuses guidelines publiques comme par exemple les guidelines d’accessibilités du W3C (WCAG), mais les guidelines du site internet d’une entreprise restent en général interne à l’ entreprise et sont estampillés «document confidentiel» et donc à ne pas divulguer.

Aujourd’hui je me suis penché sur les guidelines de la BBC qui sont complètement accessibles à tout le monde sur leur site internet http://www.bbc.co.uk/guidelines/.

Vous pourriez vous poser la question «pourquoi ?» si vous n’aviez pas été devancé par l’introduction de la page d’accueil qui indique :

Cette page vous donne accès aux méthodes, standards et guidelines de la BBC et est destinée principalement à ceux qui entreprennent ou qui souhaitent entreprendre des travaux pour la BBC en tant que fournisseur.

(This page links you to BBC policies, standards and guidelines, and is intended primarily for those undertaking or wishing to undertake work for the BBC as a supplier.)

3 types de guidelines : Editoriales, Qualité, Développement Web. Nous allons nous intéresser aux dernières.

On y retrouve par ordre :

1. Les guidelines d’accessibilité versionnées et indiquant clairement le degré d’obligation d’appliquer ces recommandations : MUST, MUST NOT, SHOULD, en majuscule et gras, difficile de faire plus clair.

On y retrouve la plupart des thématiques nécessaires pour faire un site approchant d’un degré d’accessibilité satisfaisant (ceux qui s’y sont déjà essayé savent qu’il est très dur voire quasi impossible de faire un site complètement accessible).

2. Les guidelines éditoriales et graphiques : Le premier lien renvoie vers le site GEL (Global Language Experience) où vous trouverez tout ce qui concerne le design, la typo, la construction des pages. Difficile de faire plus complet.

Le fichier pdf de la charte est téléchargeable : http://www.bbc.co.uk/guidelines/gel/downloads/GEL_styleguide.pdf (pdf – 272ko). Si vous n’avez pas compris l’utilité ou le fonctionnement d’une grille pour structurer vos pages, ce document est pour vous. Tout est très bien expliqué et documenté.
Je vous recommande vivement de jeter un coup d’œil ensuite sur le document : Mobile Design Guidelines v1.1 (pdf – 5,5mo), vraiment très instructif, qui explique comment concevoir l’interface de la version mobile d’un site.

3. Je passe rapidement sur Infrastructure, Policy et Red buttons (au passage le fichier est endommagé…), pour me concentrer sur la partie Technical. Vous y trouverez toutes les préconisations pour l’optimisation et le poids des pages, les règles à suivre pour les emails, le support des navigateurs, etc..

Bref je vous conseille d’aller faire un tour sur ce site qui est vraiment une source d’inspiration pour la rédaction des guidelines à suivre pour votre site internet.

J’en profite pour ajouter quelques exemples de guidelines que j’ai pu trouver en cherchant un peu :

– Oquast best practices
– YSlow User Guide
– Centre d’aide de Google pour les webmasters
– UI Guidelines for mobile and tablet web app design
– Guidelines pour designer sur téléphone mobile
– Email design guidelines de Campaign monitor

Toutefois mes préférées restent quand même les Christopher Doyle Guidelines (pdf – 1mo)…

La vie est belle non ? Elle s’appelle comment cette boite ?

Elle n’existe pas ! Méthode agile ou méthode agile ? Attention le lien n’est pas le même…

Après quelques années d’expériences et de nombreux clients ou de nombreux patrons plus tard, vous ne vous faites plus guère d’illusion. Oubliez les specs et réunions inutiles, après l’intégration, le debug. Je me permets au passage de citer webagency fail : [commercial] — Pour le cahier des charges c’est facile, c’est la même chose qu’Amazon. (via @cobolian).

Mais bon, on va pas faire de ces quelques cas une généralité, rassurez-moi, c’est pas partout comme ça ? si ?

Ok plus sérieusement, c’est quoi l’organisation idéale vue par un intégrateur et quelles étapes devraient être respectées dans le déroulement d’un projet ?

1. Réunion de kick-off et identification des ressources

Le chef de projet explique son objectif, répartit les tâches et présente le planning. Les intervenants corrigent ce qui leur semble important. A l’issue de la réunion, tout le monde est censé être calé sur le qui fait quoi, quand et comment. La réunion de kick off permet de créer la cohésion d’une équipe, susciter la motivation autour du projet et faire adhérer tous les participants aux objectifs à atteindre. Les points de blocages sont identifiés, les moyens à mettre en œuvre sont connus. Ensemble l’équipe va pouvoir formaliser un plan d’action réaliste.

2. Conception et wireframes

Voilà le décor est posé, on connait les acteurs, il nous reste plus qu’à commencer. Première étape, la phase de conception. Le chef de projet qui a longuement réfléchi à son projet qui a échangé avec les différents intervenants en amont (marketing, commercial, SEO, etc.) va commencer à apporter la première pierre à l’édifice. Il va poser ses idées sur le papier, faire ses découpages et collages pour imaginer les différentes pages de son projet. Il peut également utiliser des logiciels tels que Powerpoint ou Axure qui vont lui permettre de faire des interfaces sommaires et quelque fois fonctionnelles. Voilà c’est fait, il ne lui reste plus qu’à présenter son travail aux webdesigners et pourquoi pas, soyons fous, aux intégrateurs et autres développeurs qui ne manqueront pas de faire des propositions avant-gardistes comme utiliser html5 et css3 , mais je m’égare… C’est le moment où on se rend compte qu’on va un peu trop loin, que ça, ça et ça, ce n’est pas possible ou ça va prendre trop de temps ou ça va grèver les performances d’affichage, bref on affine. On fait des points courts mais efficaces, un quart d’heure suffit à chaque fois.

3. Création graphique et mise en couleur

C’est la phase de créa pure, les graphistes vont, et quelque fois c’est tout simplement magique, transformer les zones rectangulaires et froides des croquis ou wireframes en quelques chose de coloré, vivant et on l’espère terriblement novateur. Alors oui quelque fois, nous les rabats-joie, les intégrateurs, on émet des doutes sur la faisabilité, sur le poids des images, sur tout un tas de détails qui viennent contraindre leur travail, mais tout travail artistique ne connait-il pas des contraintes, hein ? Allez, on parle des grilles, grilles de 960 ? on est d’accord ? 15px de margin ? 10 ? Hum, faut voir… Bref la discussion n’est pas terminée et là encore quelques réunions et de nombreux points à aborder, on parle interface, ergonomie, accessibilité, performance, css3, font-face, il reste plus qu’à convaincre du bien fondé de tous ces choix qui vont nous permettre de construire un site moderne et actuel digne de ce nom. Il ne reste plus qu’à faire valider la créa par le client.

4. Validation du client

Alors souvent le client n’y entend rien à ce qui fait le cœur de notre métier et ne comprendra pas grand chose aux choix que nous auront fait, bref la plupart du temps 50% de notre travail sera pour lui invisible. Il insistera même quelque fois pour imposer ses choix désastreux, mais bon, c’est le client. Quelque fois le client est vraiment cool et a toute confiance en nous, après tout il s’adresse à des pros, non ? Ils savent ce qu’ils font ces gars-là ! Bon n’essayez pas de le convaincre que htm5 c’est mieux que xhtml, que là on va plutôt faire du javascript que du flash, qu’il vaut mieux faire du hover que du onclick, tout ça c’est du jargon pour lui. Il va falloir travailler la communication, les mecs ! Enfin à moins d’avoir à faire à un chieur de première, le client conscient de la valeur de votre travail, demandera quelques adaptations qui ne sont pas forcément dénuées de sens et qui permettront à tous de dire : on a fait du bon travail ensemble ! Le chef de projet se fait le porte parole de toute l’équipe, il maîtrise les fondamentaux et comprends les choix des différents intervenant. Au passage il n’est pas interdit de se faire accompagner d’un technicien qui pourra pousser plus loin la démonstration technique. Dernière chose : s’assurer que la validation du client est une vraie validation ou alors attention aux débordements…

5. Laissez les intégrateurs faire leur travail…

Voilà la phase la plus intéressante, magique et décisive pour le succès d’un projet. Bon on a tendance à se dire ça en tant qu’intégrateur, mais en fait, on découpe juste les maquettes des webdesigners, on suit les specs (quels specs ?) des chefs de projet et on prépare le travail des développeurs back qui souvent appellent notre travail, qui pourtant est un travail abouti puisque c’est ce résultat qui sera mise en ligne : les “maquettes” html. Pendant toute cette phase, on va s’acharner à convertir les maquettes graphiques en pages web qui ressembleront au plus près à ce qui a été imaginé et designé. En général, tout va bien et on est content avant de voir le premier résultat dans les navigateurs IE6 et IE7, mais arrêtons de tirer sur l’ambulance, depuis le temps on commence à maîtriser les faiblesses de ces versions… Je reviendrais plus en détail ultérieurement sur l’organisation d’une équipe d’intégrateurs et comment mettre en place des méthodes de travail efficaces, ça mérite bien un autre article.

6. On va débugger tout ça maintenant

Une fois les images découpées, les intégrations finies, les fichiers html, css et javascript livrés, on pourrait croire le projet fini, qu’on peut aller se boire une petite bière bien méritée au bistro du coin, après tout les développeurs back n’ont plus qu’à greffer leur php sur notre interface html et bien pas du tout ! Même le plus parfait des intégrateurs (mais personne n’est réellement parfait, n’est-ce pas ?) ne pourrait échapper à cette phase de test. Maintenant votre intégration est mise à l’épreuve et de nombreuses corrections sont nécessaires; c’est à ce moment là qu’on se rend compte de choses comme au choix : on a oublié la page contact ou on n’a pas prévu la cas où le client paie avec une certaine carte de crédit ou en allemand, ça dépasse, etc. etc. Les exemples ne manquent pas et pour certains projets ça peut durer des semaines et des semaines. C’est pas encore qu’on sable le champagne…

Mais dîtes voir, ça aurait pas été mieux avec des specs ?

Allez quelques ressources à lire et des conseils à méditer :

• Project management, illustrated with a tree and a swing (merci Olivier Keul ;-)
• Un blog dédié aux wireframes
• I wireframes
• Wireframes Magazine
• 10 Excellent Tools for Creating Web Design Wireframes
• Wireframes for the wicked
• Get everyone on the same page with a project kickoff meeting
• Gestion de projet : série d’articles de Régis Audugé
• Projet web : 8 étapes, 8 livrables (infographie)
  
• Cadre général de la gestion de projet web
• Méthodes AGILES: une belle définition
• Scrum méthode de développement agile
• Grille de lecture des méthodes agiles