Bonjour abonné malheureux de ce blog un peu en friche. Déjà bonne année 2009 (sur le fil) et plein de bonnes choses magnifiques pour cette nouvelle année. Le web va prendre 20% de croissance cette année alors tu es au bon endroit
En 2009 je prends la résolution de couper l’herbe et faire une peu de ménage ici, ou pas.

En attendant, j’ai été retenu par plusieurs activités très chronophages, dont le remaniement complet de mon CMS pour en virer le code HTML de 1999 et le rendre “W3C compliant” comme dirait ma cousine de Boston, alors je vais étaler ici ma science récente pour t’en faire partager les grands principes et les choix éventuels à faire pour être au top.

Déjà je voudrais dire en intro que c’est possible, chose dont je n’étais pas sûr il n’y a pas si longtemps.

1/ Le XHTML limpide

Alors on parle de Transitional, pas de Strict, pas parce que j’ai envie de lancer un débat, mais uniquement parce que c’est ce que j’ai fait

La limpidité est importante à plusieurs titre :

• déjà c’est beau à voir;
• ensuite c’est bien pour ajouter des effets Javascript genre avec mootools,  que j’aime bien;
• c’est simple et donc léger;
• Google adore;
• ça permet de styler tous les éléments super bien;
• … donc le cas échéant de faire une feuille de style pour mobile;
• si t’as d’autres choses à dire, tu les mets en commentaire, moi j’ai fini.

La limpidité c’est :

• Pas de tables foireuse inutiles pour découper ta page;
• pas de pixels pour séparer les éléments comme on faisant avant;
• pas de style, pas de propriétés sur les éléments dans le code;
• des tags bien fermés;
• une architecture lisible au premier coup d’oeil.

J’ai pas mal utilisé les DL/DT/DD (pour faire des modules au design extensible) et UL/LI (notamment pour les menus et sous menus), quelques DIV et SPAN pour découper mes éléments, des H1/H2/H3/H4 bien sûr pour Google, des alts et des titles aussi pour Google, du code HTML quoi.

J’ai appris que & s’écrivait & partout sinon c’est pas valide.

J’ai appris qu’on peut mettre un UL dans un LI pour les sous-menus.

J’ai appris qu’on mets pas un H4 dans un DT.

2/ Les feuilles de style par navigateur

Alors on code pour Firefox, on ajuste pour IE7 et on adapte pour IE6. Ca fait donc 3 feuilles de style. Et parce que les *width ou les _width c’est pas CSS2 valid, on les appelle avec :

<style type=”text/css” media=”screen,tv,projection”>
@import “style.css”;
</style>
<!–[if IE 7]>
<style>
@import “styleie7.css”;
</style>
<![endif]–>
<!–[if lt IE 7]>
<style>
@import “styleie6.css”;
</style>
<![endif]–>

3/ Le CSS2

Le coup du cursor:hand;cursor:pointer; c’était pour IE5, maintenant faut arrêter, donc cursor:pointer; c’est la bonne syntaxe.

On ne style pas les H1/H2/H3/H4/H5, ou uniquement en dépendance d’un autre truc, sinon on a des comportements aléatoires.

On utilise les em au lieu des pixels pour tout ce qui est titres, textes, interlignage, formulaires… non seulement c’est beau mais changer la taille de tous les éléments du site est facile pour le dev comme pour l’internaute. UTILISEZ-LES !
Un élément contenu dans un autre hérite du em et vient multiplier la valeur du em de l’élément.
Donc un truc à 2em dans un truc à .8em fait… 1.6em (reste avec nous). Le em de base (body) peut-être défini en pixel ou en pourcentage. J’ai pris le pourcentage, je suis joueur et c’est plus accessible parait-il.

Caler les formulaires au pixel sur tous les navigateurs est un exercice très très chronophage.
Je vous donne mes valeurs, vous en ferez bien ce que vous voudrez.

input{font-size:.8em;line-height:.9em;border:1px solid #CCCCCC;padding:0.2em;}
label{font-size:.8em;height:1.2em;padding:0.2em;}
input[type=text]{height:1.2em;padding:0.2em;}
select{font-size:.8em;border:1px solid #CCCCCC;height:1.8em;padding:0.2em;}
textarea{font-size:.8em;border:1px solid #CCCCCC;padding:0.2em;}
input[type=submit]{padding:0.14em 0.5em 0.025em 0.5em;cursor:pointer;line-height:1.475em;min-height:1.475em;}
input[type=button]{padding:0.14em 0.5em 0.025em 0.5em;cursor:pointer;line-height:1.475em;min-height:1.475em;}

Styler correctement un input[type=file] est impossible partout. C’est un champ dépendant de l’OS.

Les DL DT DD sont à utiliser pour les beaux design extensibles qu’on faisait en table. Les DT sont à utiliser impérativement pour mettre un titre. Si on ne veut pas le rendre visible, on fait un beau :

dt{display:block;overflow:hidden;text-indent:-1000em;}

D’ailleurs on peut utiliser ça pour plein d’autres choses, je vous laisse jouer avec.

4/ Les trucs à la con

Pour ce qui n’est pas IE6, on peut utiliser la syntaxe de descendance du type ul > li > ul > li, pour adresser les listes de sous-menu.

Pour IE6 on est baisé, ça marche pas, et en plus un ul > li ira aussi taper le LI qui est dans le UL qui est dans le LI qui est dans le UL (t’es perdu, c’est pas grâve, si tu as plusieurs niveaux, il sont tous impactés). Donc IE6 prend les styles dans l’ordre, donc pour adresser le li du sous niveau, mettre le style après dans la feuille. Maintenant si tu as un background sur le premier niveau mais pas dans le sous niveau, faut spécifier background:none;.

Pour IE6 encore, on ne peut pas utiliser les input[type=text] etc… donc styler input pour IE6 et spécifier ensuite pour les autres. Ca sera moins beau pour IE6, mais les gens qui ont IE6 en 2009, qu’attendent-ils du web entre nous.

5/ Les trucs super à la con

Un div en position absolute qui passe par dessus un select sur IE6 passe en fait en dessous, rien a faire. C’est un bug connu et il existe des hacks assez pointus que j’ai décidé d’ignorer pour la même raison que celle du précédent paragraphe.

Le PNG transparent sur IE6, je vous laisse chercher, c’est connu aussi. Je l’ai même pas encore mis sur mon CMS (je vais le faire quand même par contre).

6/ Les trucs perdus et c’est domage

Les align=”absmiddle”, les height=”100%”, les valign=”bottom”,  les align=”center” (deviennent : margin:0 auto;).
Aligner un footer toujours en bas de la page se fait donc en JS et c’est un peu con.

7/ Mettre à plat le markup au début

Pour éviter de subir les valeurs par défaut éventuelles et les impacts des navigateurs, on fait un reset de tous les tags au départ :

html, body, div, span, object, td, a, li … {
margin: 0;padding: 0;border: 0; outline: 0; font-weight: inherit; font-style: inherit; font-size: 100%; font-family: inherit; vertical-align: baseline;}

J’ai pas tout mis mais vous voyez l’idée…

ol, ul, ul li,li {list-style:none;list-style-type:none;list-style-position:outside;list-style-type:none;}

Notamment pour utiliser les li dans les menus…

table {border-collapse: collapse;border-spacing: 0;border:0;margin:0 0 1.25em 0;padding:0;border:none;}

Voilà… je vous laisse ajouter les truc hyper importants que j’ai pas fait dans les commentaires

Je vous laisse en partant l’adresse des validateurs XHTML et CSS2, pas la peine de tester ce blog, j’ai même pas vérifié.

Cette semaine on rêve, la politique étant au centre de l’actualité outre-atlantique, à un monde meilleur, ou en toute cas à un système qui ouvrirait, à défaut de ses chakras, ses portes à une discussion argumentée à tous les niveaux.

Cette semaine donc, un sujet qu’il est beau : La politique participative en ligne.

Quelles initiatives a-t’on pu observer, celles qui ont été intéressantes, celles qui ont complètement capoté et le rêve que je me permet de formuler, a défaut de le réaliser, rien n’est perdu ceci dit.

La discussion, qui contournera soigneusement les guerres de tranchées, sera bien entendu bienvenue, on est pas des bêtes.

Ce que j’ai aimé :

- Les initiatives, imparfaites mais réelles, des différents courant politiques pour intégrer, au moins les commentaires sinon des propositions des profils enregistrés pour les différentes dernières campagnes et réformes. On a vu des choses pour les campagnes à la présidence, pour les sujets sensibles comme les reformes des fonctionnaires, ou les initiative dans le domaine de l’environnement. Au delà de l’effet Web2.0 pendant la campagne, on note une tendance de fond, qui est de faire fructifier la discussion en ligne. Aujourd’hui on trouve énormément de blogs dans les différents courant et des communautés très active. C’est le signe que c’est possible et que ça apporte quelque chose à la politique.

- Les nouveaux outils de mesure de l’opinon, basés sur les recherches Google, sur les articles parus dans les blogs ou dans les agrégateurs qui ont permis à plusieurs reprise de se faire une idée plus tangible de l’intérêt des gens pour un sujet précis ou une personne ou au moins d’avoir un autre son de cloche que les sondages “classiques”.

- Les informations partagées en ligne par les différents courants ou le gouvernement, les propositions exposées au public avant qu’elles deviennent une base pour de nouvelles lois,…

- Le débats, quand ils ont été bien pensés (pour Ratp - Stratégie de rencontre entre fonctionnaire et usagers pour faire avancer et faire connaitre le service publique) ou spontanés (Loi Hadopi - Débat spontané sur la blogosphère et impact réel sur le projet), et même avec les débordements habituels.

Ce que je n’ai pas aimé :

- Le bide total du Figaro avec “Notez votre maire” et des autres pseudo-sites conçus pour faire de l’audience et complètement dépourvus de bon sens et de finesse. Donner la possibilité aux gens de se défouler n’a jamais permis de faire avancer le débat. L’audience sans doute, et encore, initiatives assez pathétiques de mon point de vue.

- La guerre de tranchée qui survient sur les gros site d’actu type 20minutes.fr sur chaque sujet politique chaud. C’est, malheureusement comme sur tous les sites à forte audience qui traitent de sujets politiques, une poignée d’illuminés qui sortent les armes à chaque sujet présentant un beau champs de bataille gauche-droite.
Je ne jette pas la pierre à ces sites, qui ont le mérite de laisser leur audience prendre la parole malgré la difficulté de gérer le flots de commentaires.  De plus, je n’estime pas connaitre la bonne solution au problème. On retombe sur les problématiques de profil, du karma et de modération qui sont cruciaux pour ce type de services ou système. Comment permettre aux gens de s’exprimer tout en régulant les effusions inutiles sur des sujets chauds. Certains me répètent qu’il n’y a pas de solution, cependant on doit forcément pouvoir aller plus loin.

-  Les initiatives mal pensées ou trop contrôlées qui se sont transformées en opération de com’ sans vie. Je pense à des pseudo systèmes de proposition ou ni les initiative, ni les commentaires n’ont pu être apportés du fait soit de la tension régnant autour du thème ou de l’impossibilité de tomber sur des choses constructives.

Le futur ? :

Le mouvement n’est pas vraiment réversible, le citoyen aura donc de plus en plus de façon de s’exprimer et de s’impliquer dans le débat politique. Si le vote électronique reste encore pour moi très lointain, le poids du débat citoyen devrait augmenter. Il va donc falloir inventer des systèmes plus performants pour organiser ce débat et le faire avancer.

Une solution que j’affectionne est le système de propositions, sur tous les niveaux de politique : du quartier au pays :

• doté d’un système de vote ou au moins de support, afin de leur donner des priorités,
• garantissant l’unicité de l’utilisateur ainsi que la prise en compte de la réputation/karma,
• basé sur la personne et son activité dans le système et sur l’adhérence des autres utilisateurs à ses actions, où chaque utilisateur supporte des  initiatives et non des  personnes,
• permettant que tous les éléments d’une proposition puissent être discutés et orientés par tous les utilisateurs concernés, afin que le système évolue de lui-même vers une matérialisation juste pour chacune d’elles…

Conclusion :

Les outils avancent, les mentalités aussi, du côté des utilisateurs comme des politiques. Je reste persuadé que le candidat qui bâtira son programme sur un débat de grande envergure en ligne remportera la mise en 2012. Au delà des promesses et des bons sentiments, le quidam veut avoir son mot à dire et sentir qu’il est impliqué. En ces temps ou le web permet de garantir à chacun ses 15mn de gloire, il est temps que le seul recours politique du citoyen dépasse le dépôt d’une enveloppe dans l’urne.

Vaste programme, c’est certain, est-ce-que le jeu n’en vaut-il pas la chandelle ?
Connaissez-vous des initiatives de ce genre en cours, êtes-vous concerné par cette réflexion ?

Cette semaine on prêche pour sa paroisse, une fois n’est pas coutume, mais on cherche aussi à déceler une tendance.

Cette semaine donc, je vous propose un sujet d’actualité : La création web en free-lance.

On va commencer par voir rapidement ce qu’est la création web aujourd’hui puis on va considérer l’activité free-lance du côté du free puis du client pour en dégager des tendances, des avantages, des inconvénients.

Dois-je le rappeler, les commentaires nourrissent avec plaisir la discussion qui se veut ouverte…

> La création web qu’est-ce-que c’est ?

Avant tout qu’est-ce-que c’était ?
Avant 2000, la création web était majoritairement un travail d’artisan, de passionné qui avait réussit à expérimenter avec plus ou moins de succès les différentes facettes du futur métier de “webmaster”, une sorte d’apprenti développeur/graphiste/flasheur, et il était même recruté pour ça, principalement parce lui avait déjà touché au web.

Maintenant qu’est-ce-que c’est devenu ?
Les métiers de la création web se sont spécialisés et il existe désormais énormément de compétences web utilisées suffisamment largement pour mériter d’être très bien maitrisées et donc de donner lieu à des fonctions différenciées :

• Le design web
• L’ergonomie
• L’intégration CSS/XHTML
• Le développement serveur (PHP/MySQL, .NET, JSP…)
• Le développement client (Javascript)
• L’animation Flash
• Le developpement Flash
• La vidéo
• La 3D
• L’éditorial web

Je ne dis pas que c’est forcément un poste à chaque fois, mais la personne qui prétend tout maitriser parfaitement est beaucoup plus suspect qu’auparavant.
Par conséquent les ressources à impliquer dans un projet web sont plus nombreuses qu’avant. Dans le cas d’un studio tout intégré, ça revient à plusieurs employés spécialisés dans des domaines différent, vous voyez où je veux en venir…

> Etre free-lance dans la création web

Etre free-lance dans la création web, c’est souvent être spécialisé et reconnu pour une compétence particulière et se positionner sur plusieurs agences et réseaux pour être amené à intervenir lorsqu’un qu’un besoin précis se présente pour cette compétence. Le plus dur est évidemment de construire sa réputation et son portefeuille client afin d’arriver à garantir un niveau de business récurent.

Etre free-lance, c’est bénéficier d’un statut avantageux (Maison des Artistes pour la création graphique, AGESSA pour le développement), car se déclarer en indépendant et cotiser à l’URSAFF revient plus où moins à se tirer une balle dans le pied (désolé, c’est la vérité).

Les avantages pour le free-lance sont la diversité des projets, le développement de sa spécialité, la reconnaissance de cette compétence sur le marché, la flexibilité des horaires et plannings dans une certaines mesure et l’indépendance.

Les inconvénients pour le free peuvent être le manque de structure socialisante (on travaille de chez soi dans bien des cas), la situation de précarité (au moins au début), le manque de liquidités (surtout lorsqu’on vous paye à 6 mois) et quelque fois le manque d’accès aux nouvelles technos, nouvelle inspirations (on doit rester de soi-même sur la brèche).

Le profil est donc en général le trentenaire qui après plusieurs expériences confirmées, donne une nouvelle dimension à sa carrière en mettant un premier pied dans l’entrepreneuriat.

> Faire intervenir un free-lance

De plus en plus de free-lances interviennent sur les projets web, via leurs réseaux ou par les agences, pour des besoins ponctuels ou récurrents, à distance ou en régie (chez le client).

L’avantage du free est d’abord économique, on l’emploi pour un projet bien particulier, un CDD à la journée en quelque sorte. Celà permet d’employer la bonne ressource pour chaque projet : le designer dont le style colle à l’image du client ou le spécialiste 3D qu’on apas en interne pour un client qui veut son menu sous forme de cube. C’est à dire des compétences qu’on ne peut pas se permettre d’embaucher pour 1 ou 2 projets par an ou un expert qui couterait trop cher pour des projets où il n’aurait pas de valeur ajouté la plupart du temps.
Celà permet aussi, quand le free-lance est en régie, d’apporter du sang neuf à un projet, une vision différente du projet.

Les inconvénients principaux sont que premièrement un free peut faire défaut plus facilement qu’un salarié. En principe ce n’est pas dans son intérêt bien sûr mais il n’est pas sous le contrôle de l’entreprise, c’est un prestataire externe indépendant.
Deuxièmement la facturation et le règlement peut s’avérer un peu complexe de par les organismes impliqués dans le processus.
La pérennité est un autre problème souvent soulevé : où se trouvera le free lorsqu’il faudra faire évoluer l’application.

Le bon free est donc un profil sur, avec qui on a développé unpartenariat durable.

> Conclusion

Conclusion, même si le pas n’est pas toujours facile à faire pour une entreprise ou une agence, le métier semble aujourd’hui largement s’orienter vers une utilisation de plus en plus large des free-lances.
Le réseau à une importance énorme dans l’utilisation de free-lances, ainsi que le developpement de relations durables permettant de garantir un niveau de service et l’épanouissement des intervenants, ce qui fait que les grandes agences passent principalement par des agents spécialisées dans la gestion de free-lances pour bénéficier de la relation de confiance que peut garantir l’agent.

De plus en plus de profils indépendants interviennent sur les projets à différents niveaux, et les agences n’hésitent plus à faire appel via leur réseaux ou des agences spécialisées à des experts pour apporter d’avantage de valeur ajouté à un projet.

Se lancer en free reste malgré tout un défi risqué car les profils recherchés sont très spécialisés et le réseau est le principal vecteur de succès.

Et vous, êtes-vous free ? Faites-vous intervenir des frees ? Quelles problématiques rencontrez-vous ? Quelles tendances ?

Un post qui traine depuis un peu dans mon admin… Je le publie comme Work in Progress. Vos commentaires sont évidemment bienvenus pour faire avancer le débat…

Vaste programme, et point crucial, le design, l’ergonomie et le contenu d’une page d’accueil sont hyper-importants, c’est même la seule chance,  d’une durée d’une a deux secondes dans bien des cas, de faire une impression positive.

L’enjeu : la rétention du visiteur, la captation, peu de taux de rebond comme dirait Google Analytics. En gros, ce qui va faire que le visiteur va aller plus loin dans le site et donc accéder à l’information que vous souhaitez lui faire parvenir et éventuellement passer à l’acte d’achat, à l’abonnement ou à la prise de contact selon les cas.

Et oui, cette semaine je vous propose le brulant : C’est quoi une bonne homepage ?

Vu qu’il y a autant de réponse que de homepages, j’accepte encore une fois volontiers critiques et commentaires constructifs. L’idée ici est de donner un maximum d’éléments pour répondre correctement à cette question cruciale.

Entre la home de Google et celle de Yahoo !, entre la home du site de présentation de la petite entreprise et celle de la boutique en ligne, quels sont les points communs et différences ? Quels sont les partis pris et les incontournables ?

L’identité
C’est sans doute une des seules constantes et c’est assez logique en un sens, la page d’accueil bénéficie le plus souvent d’une identité renforcée, soit par l’utilisation d’un visuel ou d’un logo plus important, soit par le placement plus central de l’identité au sein de la page. On accueil le visiteur en déclinant son identité.

Attention, cependant à ne pas faire de cette présentation la seule raison d’être de la page d’accueil, à la manière des intros flash systématiques d’avant 2000. Cette pratique peut avoir du sens dans certains cas isolés, souvent pour de l’évènementiel ou de l’image pure, mais est généralement à bannir pour tous les sites de contenus ou boutiques.

Il existe cependant des manières de contourner cette règle en réalisant une présentation courte (5 secondes) sur une page comportant des entrées cachées vers toutes les rubriques du site (Rue du commerce est un bon exemple en la matière avec sa promo suivie de liens non visibles). D’une manière générale, l’intro flash et le fameux bouton “passer l’intro” agacent le visiteur plus qu’elles ne proposent une réelle valeur ajouté.

Les entrées
La page d’accueil c’est aussi la page qui permet au visiteur d’accéder à l’ensemble du site. Le push (encart) catégorie ou produit, visuel et impactant permet d’entrer rapidement dans le vif du sujet grâce à des morceaux choisis.

Dans certains cas, le blog notamment, ce sont simplement les derniers articles classées par date décroissante. Dans le cas d’une boutique ou pourra pousser les best sellers ou les promotions, dans le cas d’un site de présentation les activités phares de la société.

L’idée générale est de pousser ce que la majorité des visiteurs vient chercher pour retenir son attention avec un premier “clic facile”. Un utilisateur qui clique ne rebondit pas, c’est un premier pas dans le site via une découverte simple.

Le menu
Exhaustif ou non, le débat cours. Certains sont adeptes de la “règle des 3 clics”, qui veut que tous les contenus soient accessibles en 3 clics, certains non. Quand c’est faisable je dirais que c’est globalement une bonne idée.

Plusieurs possibilités pour arriver à ses fins :

- Le menu déroulant : Grand classique, aujourd’hui bien maitrisé techniquement presque partout, il permet une navigation type plan du site avec menu et sous-menus déroulants.

Attention cependant à bien réfléchir l’organisation et à s’assurer que le déroulement des menus va bien se comporter. Un utilisateur qui voit du déroulant s’attend à trouver ce qu’il cherche dans le déroulant. Si ce n’est pas le cas, il n’ira probablement pas plus loin. Attention aussi aux multiples déroulants tous azimuts dans lesquels on ne se retrouve plus. Exit aussi les menus à l’architecture obscure remplie de termes seulement compris par les salariés de l’entreprise ou les concepts marketing de haut vol utilisés par 3 cabinets parisiens spécialisés.

Un menu déroulant efficace c’est un niveau déroulant avec des mots compréhensibles par votre voisin de palier grabataire.

- Le menu géant : on passe sur une catégorie et apparait un calque qui rempli la moitié de l’écran avec le plan complet de la catégorie. Certains sont fans, d’autres moins. Un avantage non négligeable est l’exhaustivité en un coup d’oeil. Bonne intégration chez Kelkoo par exemple. A réserver aux sites qui ont énormément de contenus différents auxquels il faut accéder.

- Le menu hyper-simple : A la Apple, quelques catégories très simples dans lesquels le détail sera développé. Message : Apple c’est simple…
Note : option assez en vogue, le menu simple avec les catégories ou applications principales et le “More” qui est un menu déroulant vers plus de choses. On voit même quelque fois un “Even more” à la fin de cette liste déroulante pour accéder à une page avec le développé complet. Voir Google ou Techcrunch.

- Le menu pleine page : A la Oracle, tout le plan du site sur la home sous le header. Message : Oracle c’est plein d’applications super compliquées qui font plein de trucs obscures que vous allez nous laisser gérer…

Globalement le menu donne une bonne idée de ce qu’on va trouver et offre immédiatement une image rapide de l’organisation de la société. Je dirais : “simple is beautiful”… et compréhensible par vos visiteurs.

La taille
La taille de la home à énormément d’importance, de même que la largeur du site, et jusqu’à il n’y a pas si longtemps, on raisonnait encore en 800×600. Aujourd’hui on résonne en 1024×768. Ca sonne un peu comme une loi mais c’est vrai presque partout.

Pourquoi ? Pratiquement toutes les entreprises on acheté majoritairement ces 5 dernières années du 1024×768, même pendant l’apparition des 16/10èmes considérés comme “loisirs” et donc boudés par les DSI. Encore aujourd’hui près de 40% du trafic de la plupart des sites pros est encore en 1024×768.

On regarde donc ses stats et on agit en conséquence. En dessous de 15 à 20% du trafic on pourra réfléchir à passer à la taille supérieure. Certains sites spécialisés gamers ou graphistes peuvent se passer de cette contrainte mais c’est à étudier avec attention.

1024×768, en retirant barre de défilement et menus etc… c’est 1000px de large grand max, je préfère retenir 980px et 600px de haut, 620 si on veut jouer avec les limites. Dans 620px de haut on doit donc pouvoir mettre les infos principales qui seront vues sans utiliser la barre de défilement verticale.

Apple (encore) fait dans ses catégories une “double home”, c’est à dire menu+ pushs principaux dans le premier écran, pushs secondaires et  plan du site dans le deuxième, accesible en descendant.

Cette contrainte de hauteur n’est pas vraiment applicable aux blogs et sites d’informations, qui mettent en général leurs derniers articles complets ou une liste d’extraits. On s’attend à scroller sur un site de news et sur 20 minutes on s’attend même a scroller comme un dingue

Le footer
Le footer est souvent sous-exploité, notamment sur la home. Or sur une home on a souvent un nombre restreint de liens, donc d’entrées vers le reste du site pour les moteurs.

Une bonne pratique, souvent utilisée par les blogs, est le gros footer plein de liens, voir avec un plan du site complet, qui permet de faire suffisamment de liens internes pour référencer les différentes pages du site.

SEO
SEO = Search Engine Optimisation = Optimiser son site pour les moteurs.
Donc mettre des images partout sur la home c’est très beau, mais attention à bien faire en sorte de transformer lors de l’intégration toutes ces images en éléments lisibles et référencés par les moteurs.

Les liens de la home seront traduits en catégories et le titre en introduction pour le référencement chez Google et autres. Pensez à bien utiliser les <h1> et <h2> pour architecturer le contenu comme il doit apparaitre dans les moteurs.

De plus il est important de mettre du texte lisible quelque part, plutôt en début de page pour présenter le contenu de la home en vrai texte avec des mots dedans…

Conclusion
Que votre visiteur soit un abonné, un nouveau visiteur, un expert dans votre domaine, un quidam, un moteur de recherche ou un investisseur, on doit répondre à leurs attentes par une belle porte vers l’ensemble du site. Simple, efficace, sans détours.

Il existe des cas particuliers, comme partout, qui permettent de passer outre certaines règles car les considérations qu’elles englobent ne sont pas nécessaires, souvent pour les sites d’image pure, ou les blogs dans certaines mesures…

Quels sont les homepages que vous trouvez fantastiques et pourquoi ? Quels sont les cas particuliers qui éclaboussent ces principes sans arrière pensée ? Vous avez la parole.

Cette semaine, je vous propose le rêve du psycho-geek, la Mecque du dynamique outrancier, le temple du Shadock : l’Usine à Gaz.

Dans toute conception de système informatique, il y a la volonté de schématiser la chose à concevoir, de couvrir tous les cas possibles et de tous les schématiser pour concevoir l’omni-système.

Ca part généralement d’un bon sentiment, ou d’un sentiment du devoir, de l’amour du travail bien fait.

Évidemment la réalisation sans une dose de bon sens devient vite un désastre. Comment identifier l’Usine à Gaz, quel est le danger, comment l’éviter. Certains diront que c’est du bon sens. Vraiment ?

La genèse de l’Usine à Gaz

Entre le développeur informatique et le client tout s’oppose. Et c’est bien là qu’est l’origine de l’Usine à gaz : un manque de communication, d’information, d’explication voir d’écoute entre les parties. Et c’est pour cette raison que le chef de projet est censé se positionner entre ces deux protagonistes qui ne peuvent pas se comprendre pour trouver le bon compromis.

Cependant, le chef de projet lui-même peut se faire engluer, soit par un client sourd et borné (je veux telle chose, sous telle forme, je n’y comprend rien mais c’est facile parce que je paye), soit par un développeur muet et procédurier (…), soit parce que lui-même ne saisis pas l’ampleur des dégâts potentiels ou parce qu’il perd son indépendance face aux deux antagonistes (Le client est roi, c’est le boss qui a dit, je fais entière confiance à bidule, c’est une star…).

Comment détecter l’apparition d’une usine à gaz ?

- Le schéma fonctionnel est illisible, il ne tient pas sur une page, il y a autant de tables ou de processus que de fonctionnalités, le développeur s’arrête pour se remémorer à quoi sert une partie,
- Le budget développement explose, de 30 jours on passe à 150 jours au bout de la 3ème réunion,
- Le détail est devenu plus important que la finalité dans les discussions, on entend des phrases du style “oui mais que fait-on si le client est portugais, passe une commande en dollars et se fait livrer à Monaco”,
- Des gens s’évanouissent en réunion technique.

Les danger d’une usine à gaz.

- Budget explosé, on l’a déjà dit mais c’est un des leviers principaux pour la suite donc on va le redire,
- Système impossible à maintenir, voir à faire fonctionner convenablement (temps de réponse du système, mises à jour, développements futurs),
- Donc dépression du chef de projet, projet raté, projet abandonné, projet à refaire.

Pareto, KISS, le développement itératif, et la coupe franche

> Pareto
C’est la règle d’or, à inscrire en lettre d’or et à encadrer au dessus de la table de réunion : 20% des efforts couvrent 80% des cas. Pour couvrir les 20% restants on va déployer 80% des efforts.

Alors oui, il existe des cas et des business ou il faut aller les chercher, mais tout le monde ne travaille pas dans le nucléaire où on ne peux à priori pas se permettre n’importe quoi (…cui cui cui cui…).

Entre 20 et 100, on multiplie par 5 les efforts, donc le budget et les délais. C’est la partie la plus importante à transmettre au client : quels sont les 20% qui vont multiplier par 5 le budget et les délais. Ça parle tout de suite, ça retient l’attention, c’est très vendeur, on se comprend et on décide très très vite.

> KISS
KISS, ce n’est pas qu’une bande de rockeurs psychopathes à la face barbouillé, c’est aussi l’acronyme de “Keep It Simple, Stupid”. Comment faire cette fonctionnalité le plus simplement possible, le plus léger possible, le plus facile pour tout le monde. Comment faire en sorte que quelqu’un puisse se dire “mais bien sur, c’est complètement idiot, pourquoi n’y ai-je pas pensé avant” en regardant votre solution. Plusieurs solutions sont opposables à un même problème, il en existe une qui va vous faire gagner énormément de temps et qui est probalement tout aussi valable que celle qui couvre la moitié du schéma fonctionnel.

> Le développement itératif
Avançons pas à pas, en faisant simplement les fonctionnalités principales avant de les perfectionner. Plutôt que de se faire chier passer un temps conséquent à programmer directement quelque chose de complexe ou d’incertain, juste une question : est-ce-que ça marche ? Le développement itératif c’est faire une fonctionnalité au plus simple par itérations : concevoir, programmer, tester, présenter, concevoir, programmer, tester, présenter…

…jusqu’à ce que le temps alloué à l’origine pour cette fonctionnalité soit révolu. On pourra toujours revenir ensuite sur les fonctionnalités qui demandent une finition plus avancée. Ceci permet d’orienter les fonctionnalités en cours de route et de rester dans le temps alloué à chaque fonctionnalité.

L’eXtreme programming est une technique qui fonctionne par itération et qui “permet de réconcillier l’humain avec la productivité” d’après Kent Beck mais surtout “puisque la simplicité permet d’avancer plus vite, nous choisirons toujours la solution la plus simple”… L’anti Usine à Gaz en quelque sorte.

> La coupe franche

La coupe franche c’est l’abandon pur et simple d’une fonctionnalité car elle est secondaire, c’est du “nice to have” (c’est bien si on l’a mais c’est du bonus), redondante, voir inutile.  C’est le résultat de l’analyse Pareto. Le client est déjà d’accord, il ne le sait pas encore, c’est tout. Au chef de projet de bien présenter les raisons et la finalité de l’abandon de telle ou telle partie.

Conclusion :

Une Usine à Gaz est vite arrivée, c’est toujours tentant pour un concepteur de se dire qu’il va engendrer du système couteau-suisse universel qui fait la vaisselle, tond la pelouse et règle la faim dans le monde.

Cependant c’est évitable avec quelque concepts très simples.

Au delà de la technique qui tombe globalement sous le sens pour notre époque, c’est surtout une histoire de communication entre le décideur, le donneur d’ordre et le concepteur, le réalisateur du projet.

Certains diront que cette communication n’est pas possible et je ne vais pas argumenter, c’est souvent le cas.
C’est donc le chef de projet qui doit vendre l’analyse de Pareto, vendre du simple et stupide, vendre un développement itératif, et vendre des coupes franches au client et le faire appliquer par le développeur pour pouvoir partir en vacances à temps le bien du projet.

Pour cela il doit garder la plus grande indépendance entre le donneur d’ordre et le développement afin de pouvoir garder sa ligne de conduite sans se faire engluer par les travers de l’un ou l’autre.

Cette semaine, un concept simple mais pas toujours bien expliqué : l’API ou Application Programming Interface, “Interface de programmation” d’après Wikipedia, c’est un peu court mais le sujet est vaste.

Mais c’est quoi à la fin une API ?

Ici, je ne parlerai que de systèmes “web” pour simplifier le champ de la définition. Évidemment le concept s’applique à n’importe quels ensembles de systèmes inter-connectés via Internet, un réseau interne d’entreprise ou même entre les applications d’une machine. Nous allons voir rapidement à quoi ça sert, comment ça marche et comment l’utiliser. Bande de lecteurs intrépides.

> Pourquoi une API ?

Déjà, pourquoi cet acronyme barbare ?
Application Programming Interface ça veut dire en (un peu) plus long : Inter-connexion (interface) pour la programmation (les échanges) entre applications.

Si deux applications différentes doivent discuter, s’inter-connecter pour échanger des données, des librairies de code ou même un morceau de programme complet on utilise (ou on programme) un connecteur particulier entre les deux systèmes, une API donc.

Le but principal est la connexion en temps réel notamment pour éviter la duplication de données ou de code et permettre la fluidité des informations entre les systèmes. Dans des applications légères, on peut les utiliser pour aller chercher les informations à la demande. Dans le cas d’applications plus lourdes ou des volumes de données conséquents, on utilise ces connecteurs pour réaliser des imports ou des synchronisations.

Donc si mon site portail à besoin d’afficher les données d’un autre site en temps réel, de rapatrier des résultats journaliers, un fil d’information, des enchères eBay, une carte (et le moteur) Google Maps ou si à l’inverse je dois fournir des données que je mets à jour chaque jour directement sur un site partenaire, alors j’utilise une API…

> Comment ça marche ?

Généralement le processus implique une demande d’information à laquelle on renvoie des données ou du code. L’inverse peut s’imaginer aussi, un envoi de paramètres auquel on renvoie une confirmation ou un état pour vérification (dans le cas d’un enregistrement de compte à distance par exemple).

C’est de tout façon une requête, avec un nombre de paramètres normalisés entre les parties à laquelle on retourne une réponse, elle aussi normalisée. Le format largement utilisé en ligne est la requête HTTP et la réponse XML, cependant certaines requêtes se font par exemple directement en paquets IP (plus léger, un peu geeky quand même) et certaines réponses peuvent être par exemple directement du code Javascript à exécuter (ce qui se passe dans le cas de l’API Google Maps). L’API étant un concept assez large, les formes qu’elle peut prendre sont très diverses.

> Qui peut faire une API ? 

Tout individu ou organisme qui doit partager des données avec un autre site ou système distant. Je dois fournir des données spécialisées extraites de mon CMS en temps réel à un portail d’experts, je code une API pour leur permettre de venir chercher mes données directement. Si je veut fournir un service B2B à des sites en marque blanche, peut-être vais-je permettre à des sites partenaires de créer des comptes utilisateurs à distance sur mon système via une API. Encore une fois les applications sont nombreuses tant le concept est vaste.

 > Ou trouver des APIs ?

ProgrammableWeb fournit la plupart des APIs développées par les gros acteurs du marché : Google, Ebay, Yahoo, Microsoft, Amazon…

Ce site fourni aussi un grand nombre de liens vers des Mashups ou “applications composites”, toujours selon wikipedia, qui utilisent une ou plusieurs APIs en les combinant entre elles ou avec d’autres données pour créer un nouveau service. Afficher les enchères eBay sur une carte Google Maps, localiser tous les revendeurs d’un réseau sur une carte Google Maps, etc…

Certains de vos partenaires ont peut-être déjà créé une API pour promouvoir leur savoir faire ou faire bénéficier leur réseau de la valeur ajoutée apportée par l’utilisation de leur service. Peut-être ont-ils la volonté de le faire et qu’ils attendent une opportunité pour se lancer. L’API n’est pas l’apanage des gros acteurs, elle peut dans beaucoup de cas être développée rapidement et apporter une valeur ajoutée facilement à tous types d’acteurs.

> Comment mettre en place une API existante ?

En général, les services qui proposent des APIs fournissent la documentation associée (c’est mieux). Elle est, dans le meilleur des cas, accessibles très simplement en ligne, notamment chez Google. Certaines organisations proposant des APIs transactionnelles ou sensibles demanderont l’adhésion à un programme et valideront les applications utilisant l’API dans une sandbox (bac à sable pour développeur web, ils sont joueurs ces développeurs), eBay et Amazon sont dans ce cas. Dans le cas d’un simple flux XML, il faudra décortiquer sa structure pour programmer sa lecture et son affichage. On peut trouver beaucoup de bouts de codes pour ce type d’opération assez facilement en ligne.

> Comment coder une API ?

Dans le cas d’APIs simples, l’exercice consiste surtout à récupérer les variables soumises et à écrire une réponse XML valide. Dans le cas ou beaucoup de données sont amenées à être soumises, on demandera un format XML en entrée.Bien sûr votre API peut retourner autre chose que du XML. Encore une fois le concept est large et les applications illimités. De toute façon la réponse sera retournée par un langage serveur, il vous faudra donc savoir programmer dans le langage de programmation utilisé par votre serveur web : PHP, Python, Perl, Ruby, .NET, JSP…

> Conclusion

Conclusion pas grand chose, l’API est la pierre angulaire du web collaboratif, elle permet aux services de s’inter-connecter pour offrir plus de fluidité aux applications et une valeur ajouté accrue aux utilisateurs. Pour les développeurs c’est aussi un champ des possibles illimité pour offrir des fonctionnalités toujours plus pertinentes grâce à l’utilisation de services déportés.

Qu’en pensez-vous ? Vos expériences, questions, remarques sont les bienvenues comme toujours.

Vous connaissez Facebook, vous l’utilisez, vous avez suivi comment Facebook a bouffé MySpace.
Vous suivez les différentes évolutions des différents services Google : Reader, Mail, Picasa, Chrome, Maps, Groupes, Open Social, YouTube…
Vous utilisez les différents services Google, au moins 4 de cette liste, et surveillez leurs évolutions…
Vous suivez peut-être les évolutions qui permettent d’inter-connecter ces différents services entre eux.
Vous vous dites qu’on pourrait peut-être aller plus loin dans la démarche…

Moi aussi…

Cette semaine, dans Picasa, on peut retrouver les têtes de ses potes. Au delà de la “simple” reconnaissance faciale et du re-coupage avec les têtes existantes, il y a une évolution assez intéressante, on vous propose vos contacts Gmail, et même la possibilité de les éditer directement dans Picasa. Du coup ça fait des têtes sur des contacts.
Du côté de Gmail, on pouvait déjà accéder à Picasa pour choisir des photos à mettre sur les contacts et dans Gtalk, reste a pouvoir choisir une des têtes du contact. On pourrait afficher ça dans les groupes par exemple ou peut-être sur les recommandations de ses potes dans Reader. En tout cas ça devrait absolument être proposé dans le profil… ha tiens, faut que j’installe Lively sur ma vielle poubelle en attendant la version Mac pour voir comment ça se connecte au reste.

Aaarf, c’est vrai, Orkut, ca sert juste pour le dev d’Open-Social, ils ont essayé, c’est petit, ca marche pas, ils ont laissé tombé…

 Je continue la série sur les sujets sensibles en création web : cette semaine, un sujet redondant, élimé, qui a vu des générations entières se déchirer dans le sang et les larmes (bon OK, peut-être pas quand même), mais qui demande encore souvent d’être bien expliqué voir débattu pour éviter de se trouver coincé lorsque on monte un projet web.

Flash ou pas Flash ?

Autrement dit, quand est-ce-que Flash a du sens, quand est-ce-qu’il en a moins, que peut-on faire en Flash, quels sont les plus, les moins, les mites mythes et les réalités. Encore une fois, vos commentaires viendront renforcer ce post avec plaisir.

Je vous propose de voir les avantages/inconvénients de la technologie puis d’aborder les différents cas possibles, mais avant tout : Keskeucé ?

> C’est quoi Flash ?

Flash c’est avant tout une technologie d’animation vectorielle pour Internet. Ça se présente sous la forme d’un module inséré dans les pages grâce à une balise. On peut avoir plusieurs animations Flash par page, une seule animation qui prend toute la page. L’insertion se fait aujourd’hui principalement en utilisant Javascript, notamment pour permettre de proposer un contenu alternatif à lire pour Google et consorts ainsi qu’au navigateurs non équipés de plugin Flash.

Flash est programmable, grâce au langage ActionScript, ce qui permet d’en faire une mini application et quelque fois une vrai application. Flex est une sorte d’évolution de Flash qui va plus loin dans la programmation.

> Pourquoi Flash ?

Les avantages de Flash sont entre-autres :

• que c’est une technologie très répandue, ce qui veut dire que la grande majorité des utilisateurs le lisent sans avoir à télécharger quoi que ce soit et ce qui fait que YouTube par exemple l’utilise pour son player vidéo (en plus du fait que le streaming vidéo est bien géré par Flash);
• que c’est un moteur vectoriel, ça permet de faire des animations évoluées et interactives qui restent légères, ce qui explique donc que les animations graphiques, les jeux en ligne ou les bannières de pub sont en Flash par exemple;
• que l’ActionScript permet une très grande interactivité dans un environnement graphique évolué, ce qui fait que l’application Picnik de traitement de photos est en Flash par exemple;
• que c’est beau quand c’est bien fait et donc impactant en terme d’image, et c’est pour ça que le site de Corona ou des Agences sont en Flash;
• Edit : que Flash c’est compilé et donc que c’est le plus souvent un seul fichier (qu’on peut envoyer par mail) et qu’on accède pas à la source facilement.

> Pourquoi pas Flash ?

Mais Flash comporte des inconvénients, ils sont entre autres :

• que c’est pas bien référencé - oui il parait Google commence à lire dans Flash, mais je me permet de mettre de très gros bémols un peu partout - notamment en ce qui concerne l’architecture du contenu, le linking, la profondeur des animations, je ne crois pas qu’on puisse décemment déclarer les Flashs “référencables”;
• que c’est rarement bien fait, intégré, propre, navigable car c’est une technologie qui reste chère et quand même pas toujours facile à bien maitriser, notamment lors de l’utilisation de composants;
• que ça n’est pas encore vraiment lisible partout, notamment sur les mobile;
• que ça devient malgré tout assez vite lourd dans bien des cas;
• Edit : que Flash c’est compilé et donc que si on a perdu la source, on doit tout refaire.

Bien sûr, il existe de belles, de très belles réalisations et des façons de palier à tout ça. Chacun prêchera pour sa chapelle. Le tout est d’être au courant de ces inconvénients et d’adapter la conception en fonction.

> Le full Flash

Le full Flash c’est un Flash qui s’ouvre en pleine page, on navigue dans le flash. Le site entier est donc inclus dans le Flash. C’est graphique, beau quand c’est bien fait et navigable quand c’est bien réalisé. En général, c’est la solution choisie par les entités ayant besoin d’une image forte ou d’une interactivité accrue, les grosses marques, les agences, les créatifs, les photographes, les applications graphiques…

Par le passé on voyait souvent le site dupliqué en HTML avec un choix à l’arrivée, c’est une solution un peu vieillotte. Désormais, grâce à SWFObject on pourra composer une page (et d’autres derrière) qui seront ouvertes par les navigateurs qui n’ont pas Javascript ou Flash ainsi que par les moteurs.

Sachant qu’il est moins aisé de faire bouger la structure d’un site en Flash dans le temps et dynamiquement, on réserve ce type de solution à des sites dont la géométrie ne change pas trop. Attention, s’il est tout a fait possible de faire un site full Flash dynamique géré par un CMS, le cout est généralement bien plus important et les modifications beaucoup plus chères. Nike peut s’offrir un site full Flash dynamique et le maintenir mais ce n’est pas le cas de n’importe qui. Sans aller jusqu’au CMS, on pourra aussi fonctionner avec des fichiers XML à modifier directement pour changer le contenu qui doit évoluer dans le temps.

> L’hybride

L’hybride c’est le Flash là ou il faut, c’est un peu le beurre et l’argent du beurre. C’est le site HTML/CSS/JS bien référencé avec une galerie photo dynamique en Flash, un panorama 360°, un module de simulation en Flash, un player vidéo, une belle image animé à la place d’une image, etc…
Ça demande souvent de bien gérer les interconnexions en XML, de soumettre des paramètres à Flash, de demander à Flash d’appeler des fonctions JS dans la page, bref de savoir bien jouer avec.

> Le pas Flash du tout

Le pas Flash du tout c’est Apple.com, c’est Google, c’est souvent l’utilisation des Frameworks Javascript pour tout ce qui est effets, galeries, menus, sliders, carrousels et même le fameux coverflow d’Apple. Attention, Javascript aussi a ses inconvénients, les frameworks JS demandent aussi d’être bien intégrés, mais l’avantage c’est qu’on peut référencer pratiquement tous les éléments dans une architecture détaillée, qu’on peut dé-corréler le style et les éléments ou le code JS, ce qui est plus facile à maintenir (donc moins cher) et à monter sur un CMS. C’est la solution “élégante” pour les geeks développeurs car bien segmentée.

> Conclusion

On voit de moins en moins de sites full Flash ou en tout cas aux endroits où ce n’est pas vraiment utile. L’avènement d’Ajax et des frameworks Javascript on apporté une interactivité qui permet bien souvent de remplacer Flash avantageusement.

Certaines choses ne peuvent cependant se faire qu’en Flash, ou plutôt c’est la solution qui s’impose, c’est le cas du player vidéo, du jeu en ligne ou du slideshow photo par exemple (quoique celui de Picasa ne soit pas ridicule sur ce terrain). Pour ce site, c’est le pluggin de commentaires Seesmic qui a du sens en Flash. De même quand on veux faire un site évènementiel très interactif et visuel, ça reste quand même la solution privilégiée à l’heure actuelle.

Edit (encore) : Apparemment un Photoshop-like vient de sortir en JS, ce qui est, en plus d’être un sacré challenge, la preuve que Flash recule encore un petit peu.

Fin de l’été, de retour au clavier. Alors je me dis que je vais lancer une série de sujets sensibles dans le métier de la création internet, de façon simple. Cette semaine (là on dirait presque que je vais faire de l’hebdomadaire) :

Mais combien ça coute un site ?

Cette question est légitime, nécessaire, banale. Si je veux un site, je veux aussi savoir combien ça coute. Sauf que bon, le problème avec cette question c’est qu’elle est bien trop vague pour que quelqu’un de censé y réponde en l’état.

J’entends par là quelqu’un qui a l’intention de produire le site en question et de le facturer au prix annoncé, peu importe le montant. Et oui car il ne faut pas croire qu’en balançant une rondelette somme au hasard l’affaire est pliée. Quelqu’un qui paye s’attend à en avoir pour son argent. Donc si c’est d’argent qu’il s’agit, on ne compte plus les heures, erreur fatale.

Quelqu’un m’a donné comme solution d’opposer à cette question la réponse suivante : “le prix d’une voiture”. C’est aussi vague que la question et ça permet de rebondir ensuite sur le spectre des possibles entre la 205 diesel millésime 84 du voisin et la dernière Bentley Continental GT. Je trouve que ça a par contre le désavantage le braquer un peu le client. Ça dépend qui on a en face bien entendu. De toute façon c’est pas une réponse.

La réponse à la question :
La réponse à la question est “ça dépend du site”. Super réponse de normand, merci bien, super ton post, je reviendrai.

La vrai réponse à la question :
Lorsqu’on considère un site (un extranet, une application en ligne…) il y a plusieurs couts :

• Les couts de mise en place (de création);
• Les couts de fonctionnement.

> Les couts de mise en place

Un site c’est une partie graphique, un squelette, de l’intelligence, du paramétrage (et des tests) plus tout un ensemble de choses, assez souvent inutiles (pas toujours) mais dont on parle en premier car “ça fait pro” ou “ça claque”. On peut mettre le plus souvent dans cette catégories les animations flash, les gifs animés, les sons et musiques, le truc qui fait papa-maman mais dont personne ne saura se servir…

faire la différence entre la fioriture et le plus internaute sera l’objet d’un autre post, de toute façon ces choses tombent dans une des autres catégories d’une manière ou d’une autre.

Les couts de mise en place se comptent en jour/homme pour tout ce qui n’est pas matériel évidemment. Cependant posséder ses propres serveurs est à mon sens un métier vraiment différent de celui de la création web. Je préfère largement sous-traiter cette partie à des hébergeurs purs. En général je les laisse même passer en direct pour éviter la gestion commerciale de cette partie, chacun sa stratégie, ça représente cependant un revenu complémentaire récurrent donc intéressant dans les cas ou les clients ne veulent s’occuper de rien.

- Partie graphique :
Pour un site vitrine, dans la plupart des cas, on pourra se contenter de 2 à 4 jours de design pur, c’est à dire l’intervention d’un graphiste de niveau bon à très bon qui va retranscrire l’identité du client en ligne, prévoir la vie du contenu dans le site et réaliser les différents canevas/templates (je parle de canevas et pas de pages car je parle principalement de sites dynamiques, c’est à dire modifiables par une administration, même sommaire).

Dans le cas d’un site complexe, transactionnel ou très graphique on peut passer 10 à 15 jours sur la direction artistique (DA) et jusqu’à beaucoup plus bien entendu pour des sociétés qui veulent un traitement graphique pointu.

Le cout d’un jour/homme pour la partie graphique se négocie entre 400 et 700 euros en 2008.

- Le squelette :
Le squelette c’est la structure de ce qui s’affiche à l’écran. C’est le HTML (+CSS). C’est primordial pour deux raisons :

• Compatibilité sur les différents navigateurs/appareils;
• C’est ce que lit Google, donc c’est LE truc à ne pas sous-estimer.

Je sens qu’on va me parler de plein d’autres raisons mais tant mieux. Je n’ai pas envie d’aller plus loin pour le moment. Le squelette c’est autant de pages à produire que de canevas/templates (note : concept redondant qui sera abordé dans la partie intelligence) sachant que la première pages est la plus longue à produire normalement. Ca varie souvent entre 2 et 4 jours a peu près proportionnellement à la partie graphique.

Le cout d’un jour/homme pour la partie squelette se négocie entre 400 et 550 euros en 2008.

- L’intelligence :
L’intelligence, c’est l’évolution des données du site, l’interactivité, le tri, la vie (ok je m’emballe). Ca dépend de ce qu’on veut faire, évidemment, ça dépend donc du besoin. C’est le développement, les abréviations extra-terrestres du type PHP, SQL, Ajax etc…

Certains sites ne sont pas du tout “intelligents”, c’est à dire qu’ils sont figés, sans base de donnée, c’est de plus en plus rare mais ça peut encore avoir du sens dans le cas d’une information vraiment figée. Une information publiée une fois pour toute (résultats, rapports, états) ou temporaire (évènement, info figées dans le temps, site temporaire).

La plupart des sites ont un ensemble de pages qui sont mises à jour dynamiquement (via une administration en ligne), présentent la possibilité d’ajouter des pages, un formulaire de contact et au moins un type de données variables. Keskidi ? Ce blog est l’exemple type de ce type d’architecture :

• A propos est une page, je peux en ajouter d’autres dans le menu du haut, genre “mes références” ou “mes amis” ou “mon chat”;
• Contact est mon formulaire de contact, classique, basique, rien à dire;
• Les news ou posts ou actualités sont un type de données variables. J’affiche les dernières en home, je peux les présenter par date, par catégories, par élément simple, par tag, par recherche. Bref dans tous les sens, c’est beau, c’est intelligent, c’est pas moi qui l’ai fait, c’est Wordpress.

Ce qui me permet de rebondir sur la création de l’intelligence et donc le nombre de jours nécessaires et donc le cout. Dans le cas d’une architecture “simple” de type blog, site vitrine, galerie d’image, forum… Il existe désormais beaucoup d’outils avancés de type CMS qui permettent de réduire le temps de création (programmation), j’ai bien dit réduire, pas supprimer. Parmi ces outils Wordpress, Drupal, Joomla… qui peuvent être utilisés de bien des façons, souvent pour autre chose que des blogs d’ailleurs, et qui ont l’avantage de présenter énormément de plugins pouvant faire tout un tas de choses (donc autant d’intelligence en moins à pondre).

Il est donc important de bien comprendre que pour des choses apparemment très proches on peut passer rapidement de 3 jours à 30, c’est que plus on s’éloigne de ce que fait l’outil plus on doit générer de l’intelligence, avec tous les cas particuliers, vérifications, sécurité, optimisations pour le référencement etc… que ça implique. Dans le cas d’un site qui ne s’approche pas d’un CMS, on utilise à partir d’une certaine taille les frameworks pour réduire les temps de développement. Les frameworks sont les briques Lego de la programmation, des ensembles de bibliothèque et de structures qui accélèrent le développement.

Ha bah on est bien avancé ! Oui et non, en fait cette partie se juge à la tête du développeur qui est en face. Plus il fait des têtes bizarres, plus c’est cher. Moins ses sourcils bougent, plus c’est facile (et donc moins c’est cher).

Si la méthode précédente n’est pas disponible, l’idée est de coller le plus possible aux outils open-source existants et de les combiner, le cas échéant, de la façon la plus adaptée. La tendance c’est kiss (Keep It Stupid, Simple) dans le web, c’est à dire simple, facile, léger, rapide, agile. Plus on aura de types de données différents à traiter, plus on complexifie la manœuvre bien évidemment.

Je répond rapidement à la partie canevas/templates ici. Ce blog utilise en gros deux canevas, deux manière de présenter les contenus, et encore je suis sympa. En général une présentation en liste et une présentation pleine page (ou information dépliée). Le code fait ensuite rentrer les bonnes données dans les bons affichages. Bien sur le deuxième est plus simple à produire car on garde l’en-tête et le pied de page + une partie de la colonne.

Le cout d’un jour/homme pour la partie développement/intelligence se négocie entre 600 et 1000 euros (et +) en 2008.

- Le paramétrage (et les tests) :

L’environnement n’est jamais le même, les sites ne sont jamais pareil et donc on a toujours besoin de temps pour paramêtrer et tester que tout fonctionne bien, c’est une étape qui intervient à la fin du processus, elle est donc comptée pour pouvoir revenir un peu sur des détails, fignoler, faire marcher le site là où il va fonctionner. Cette partie est dépendante de ce qui est réalisé et comment. Pour un développement 100% maison, on peut compter 20% du temps en plus. Pour un CMS c’est plus de paramétrage et moins de développement pur et à priori moins de tests. Pour des sites simples, vitrine etc, on comptera une journée ou une demi-journée au tarif développement la plupart du temps.

Dès qu’on parle d’interconnexion entre système distants (APIs bancaires ou autre, développements maison pour interconnecter des sites ou faire circuler des données entre différents systèmes) on peut faire exploser les temps de paramétrage/tests car c’est très souvent plus dur à faire marcher qu’à coder.

Attention, dans le cas où les serveurs sont paramétrés par les développeurs du site, on pourra compter du temps supplémentaire.

> Les couts de fonctionnement

Ca peut aller des modifications éditoriales dans le cas des sites statiques aux couts de location/maintenance du serveur ou aux frais bancaires. Les couts de fonctionnement peuvent aller de 150/200 euros par an pour un petit site vitrine sans trop de trafic, géré par le client sur un CMS éprouvé à des dizaines de milliers d’euros de location ou maintenance de serveur, bande passante, etc pour des sites transactionnels importants.

Indépendement du traffic, la bande passante nécessaire explose dès qu’on parle de gros volumes de données (vidéos, photos HD, imagerie).

> Conclusion

Conclusion je n’ai pas donné de prix, ce qui était bien le but du billet, mais j’espère avoir donnée une idée des postes de dépenses et des mécanismes de pricing. A noter que le prix du jour/homme ne fait pas tout. On peut avoir quelqu’un de pas cher qui bosse lentement et quelqu’un de plus cher qui bosse plus vite…

Edit : Lisez les commentaires très constructifs, merci les gars, ça fait plaisir Je pense que je vais continuer dans cette voie.

A l’origine de ce post des discussions passionnées ici et là sur comment se reposer sur le “user generated content” pour propulser son contenu vers le nirvana une meilleure indexation grâce à la diversité bénie du lecteur-commentateur.

Le bas blesse assez méchemment lorsqu’il s’agit de faire participer la plèbe le plus grand nombre sur un sujet d’actualité passionnant et sensible, prennons un exemple au hasard : Les grèves.

On demande son avis au lecteur, voir on lui demande pas mais il le donne quand subitement le post part en sucette, “lâche ton com” comme dirait un skyblogueur, “et vous qu’en pensez-vous” pour les autres. Le sujet est sensible, les avis glissent carrement vers une mauvaise fois déguisée en argument choc, le post part en live.

Résultat : lâche plus du tout ton com. D’autres sont passés par là, les techniques sont multiples.
On ferme les commentaires. Beurk, la censure c’est dégeulasse.
Le philosophe se demande quels sont les effets pervers d’un système automatisé pour modérer automatiquement les commentaires en s’appuyant sur l’ensemble des lecteurs. Le résultat quand la moitié est pour et l’autre contre c’est que le système ne sert à rien.
On parle de moyens humains indispensables pour modérer les commentaires, et puis on finit par demander au lecteur de créer un compte.

L’email est en effet (avant qu’OpenID soit largement utilisé) ce qui défini le mieux l’identité numérique à ce jour, et créer un compte permet parfois de modérer un peu les ardeurs. 20 minutes est d’ailleurs un bon exemple, on a tous les systèmes sus-cités combinés, oui mais c’est toujours pas ça. En plus, créer un compte, c’est relou contraignant, et on a dit pas d’entraves à la création de contenu, ça référence.

Alors je me dit, pourquoi pas laisser n’importe qui commenter, email obligatoire, c’est déjà le cas, on vérifie (avec le cliquage de lien dans le petit mail mon ami) le email la première fois, le commentaire est publié après vérification. Déjà plus d’Anonymes.

Ensuite on modère les commentaires 2 possibilités :
1 -Le commentaire est pourri, de mauvaise fois caractèrisée, ne sert à rien. On le grise, c’est un avertissement, l’avertissement est visible au dessus du commentaire qui lui est grisé et pas vraiment lisible. Le bonus : 3 avertissements = blacklist.
2 - Le commentaire est insultant, raciste, … = blacklist direct.

On blackliste et on whiteliste dans la même liste (je sais c’est pas français).
Avec ça, tu effectues une sorte de pseudo karma binaire que toi t’as décidé, ça tombe bien t’es seul maître a bord, et c’est toi qui mets des plus et des moins sur les coms, t’attends pas que X gars notent un truc pour le voir disparaître.
Ha oui, et tu annonces ta méthode au niveau de l’écriture et de la validation du commentaire. La blacklist c’est X (jours/semaines/mois) sans pouvoir commenter et commentaire non affiché bien sûr.

Alors tu vas me dire (et t’as raison):

- “Finalement ça revient à une création de compte”. Oui, mais sans entrave autre que la vérification du email la première fois.
- “Oui mais n’importe qui peut utiliser ton mail”. Non, tu envoies un mail automatique à chaque commentaire généré avec un lien pour le supprimer si c’est pas toi qui l’a pondu. Si tu as été blacklisté dans l’intervalle, tu restes blacklisté (déblacklistage possible après négociation avec toi-même mon ami).
- “Et finalement ça fait autant de travail de modération”. Oui au début, mais tu devrais commencer à tirer rapidement profit du système.
- “C’est à dire ?”. C’est à dire que ta blacklist, c’est déjà ça de moins de glands qui commentent avec les pieds, on va mettre le délai à 1 mois de blacklisting pour voir, tu peux faire plus, c’est toi qui mets le curseur, et tu peux même monter le curseur au fil du temps. Les commentaires pourris, c’est 3 max, ensuite c’est un tour en cabane et on utilise son deuxième email qu’on garde pour faire les choses sérieuses.
- “C’est pas un peu de la censure ?”Bah tu qui gère ton système de validation, si les gens se sentent censurés c’est que tu n’as pas bien expliqué les règles.
- “OK et comment je le mets dans mon WordPress ?”. Et bien, il faut le coder. C’est pas la mort, faut un peu de temps.

En passant on arrête le spam… Je dis ça, c’est pour l’effet bonus.

C’est quoi que t’en penses, malheureux lecteur de ce blog oublié ?  Allez, Lâche ton com’.