J’ai eu le même étonnement à Paris-web, croiser des gens qui ont les mêmes pistes de réflexion alors qu’on ne s’était jamais rencontré dans une des quatre dimensions, c’est proprement étonnant : surtout sur des équipes totalement différentes.

Le jeu en vaut totalement la chandelle ! 😀
Sans faire de la qualité pour la qualité, ça amène des gains de productivité, moins de stress pour les équipes, du renouveau, etc.
Typiquement, quand mon collègue commence à lorgner sur mes techniques car elles lui font gagner du temps ou qu’il a envie de s’amuser avec HTML5, je me dis que c’est super que ce que j’ai fait l’ai motivé à tenter. 🙂

Si je montre les limites, c’est par simple pragmatisme : j’aime montrer que les choses ne sont pas manichéennes, il y a un juste milieu à tout… mais c’est très personnel. 🙂
Et ça n’invalide pas l’idée de base, bien au contraire, j’en suis totalement convaincu.

Je constate les mêmes choses en tout cas : les mauvaises habitudes s’effacent (+ ou – lentement), la qualité amène une chose : le plaisir et la fierté du travail bien fait. Et ça, ça motive une équipe.

Et accessoirement, ça la blinde le jour où elle va devoir se frotter à un projet tellement énorme que tout va être mis à l’épreuve : qualité, nerfs, limites, etc. là aussi, c’est du vécu, quand toute l’équipe est lancée dans l’arène et que c’est la guerre, elle a intérêt à être soudée si elle veut s’en sortir.

Bref, les choses vont dans le bon sens. Merci pour ce compte-rendu.

Merci Nicolas pour ta réponse.
Il est bien évident que l’inclusive development et l’amélioration continue sont des principes de travail qui ne sont adaptés qu’à des typologies de projet spécifiques. Tous les projets ne pourront pas prétendre à ces préceptes. Tu le soulignes, les raisons peuvent être diverses et valables : un site événementiel (qui aura donc une durée de vie courte) n’aura pas les mêmes besoins qualitatifs qu’un site e-commerce (dont les contraintes en terme de performances, de sécurité, de suivi et de réactivité font partie des priorités). Cependant, le principe est de tendre vers cette démarche et de s’habituer (soi-même et les équipes avec qui on travaille) à avoir les bons réflexes. J’ai pu m’en apercevoir, au fur et à mesure, les réticences laissent place à la compréhension puis à l’adhésion. La mise en pratique peut être longue car elle peut bousculer fondamentalement les (mauvaises) habitudes prises par tous.
Concernant les équipes éclatées et/ou nombreuses, c’est le rôle du chef de projet et du responsable qualité web de coordonner les efforts et de mutualiser les connaissances. Tout dépend de la volonté et de l’investissement de chaque intervenant sur un projet donné.
Dans tous les cas, le travail sur la qualité (web ou non) demande des efforts constants.
Mais le jeu n’en vaut-il pas la chandelle ? 😉

C’est ce que j’essaie de faire quand en tant qu’inté, j’explique par exemple à mon graphiste de travailler sur ses maquettes les contrastes de manière à les rendre accessibles, où quand on se met autour de la table avec le responsable Google Analytics pour penser « structure de site » afin de pouvoir en tirer des objectifs afin de chiffrer les ROI d’un processus ou même du site (par exemple, mais il y en aurait beaucoup).

En pratique, je relativiserais : l’inclusive development est une pratique que je fais depuis quelques années en enrichissant le socle de départ de mes sites, donc au final, c’est de l’amélioration continue (je me suis rendu compte que comme Mr Jourdain, « je faisais de l’inclusive development depuis plusieurs années sans le savoir »).

Néanmoins, je la tempèrerai par une réalité de terrain : sur bon nombre de projets, je fais des one-shot : une fois le site pondu, ni le client ni nous-mêmes ne pouvons (pour des raisons très valables : budget, disponibilité, non-besoin) y revenir sans cesse pour améliorer. Donc dans ce cas, le duo Kaizen/inclusive development trouve ses limites.

Autre cas de figure : j’ai pour ma part la chance d’avoir toute mon équipe dans le même bureau, donc les discussions qualité peuvent aller bon train de manière informelle et très rapide. L’équipe étant restreinte et une certaine liberté étant offerte, les décisions peuvent être prises très rapidement, sans avoir les lenteurs d’un pachyderme.
Imaginons une équipe nombreuse et très éclatée, la communication peut être plus délicate, et donc l’amélioration freinée. Dans ce cas, la question serait de savoir comment mettre en place ce système dans une réalité qui lui est peu favorable ?