“Specs” ou spécifications fonctionnelles, vous connaissez ? Vraiment ? Bon, si vous expliquez votre métier d’intégrateur, il y a bien un moment ou vous aller en parler. Vous travaillez en général à partir d’une maquette graphique et d’un brief qui va lister et expliciter en détail les fonctionnalités de l’interface que vous allez construire. Si tout va bien, vous avez discuté des wireframes avec le chef de projet qui a organisé une réunion de kick-off avec les intervenants qui vont constituer l’équipe du projet ; en règle général : un chef de projet, un directeur artistique, un ou plusieurs webdesigners, un ou plusieurs développeurs back, un ou plusieurs intégrateurs (ou développeurs front), pourquoi pas un ergonome, etc. (la liste n’est pas limitative, mais on travaille mieux lorsque l’équipe est réduite, question de communication). Vous avez également pu faire valoir votre expertise – le domaine d’intervention de chacun est connu de tous, vous vous êtes vu plusieurs fois avec les webdesigners qui créeront les maquettes en intégrant vos contraintes : utilisation d’une grille, utilisation de css3 tout en prenant en compte les principes d’amélioration progressive ou de dégradation gracieuse, vous avez pu parler d’accessibilité, etc.

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