Piège en haute mer

29 jan 2015

A propos des cours en IUT, j’ai souvent de grandes conversations avec mon collègue Steve Beau qui lui aussi est intervenant. Je lui expliquais les limites d’exigences technique sur les élèves par rapport à mon manque d’emprise sur l’ensemble de la formation.

L’exigence

La formation de jeunes apprentis demande une certaine capacité à pouvoir faire se concentrer des élèves à la réalisation de tâches immédiates, répétitives ou fastidieuses et en même temps à les projeter dans des conditions probables de production in the « real life ».

La question étant de jongler entre le besoin de leur faire maîtriser correctement certains concepts et leur capacité à s’intégrer à une équipe. Le but étant qu’ils sachent estimer où peu se situer un blocage dans le processus afin de demander de l’aide à la bonne personne.

Avec Steve, on parlait des préprocesseurs en me signifiant que ses élèves ne voyaient pas leur utilité puisque, pour l’exercice, il fallait écrire plus de mixins que ce qui était nécessaire en CSS classique ; il y avait plus de code dans les fonctions que dasn le code qui était généré.

Steve de soutenir qu’il importait de leur expliquer que dans un cas de production, cela s’avérait bien utile car le code pouvait être très complexe. Mais à moi de lui répondre que le cas de production n’étant pas précédement vécu (l’expérience), ce discours restait difficile à appréhender pour la majorité des élèves.

Vents et marées

Steve n’a pas tord de soutenir qu’il faut les préparer à la complexité de leur furtur métier en leur expliquant les cas pratiques. Cependant, cette conversation m’a amené à développer l’idée que la classe était un peu comme de l’entraînement en piscine.

Dans un cours, les exercices sont préparés, le déroulement normé afin de permettre de garder un niveau homogène entre des élèves différents qu’il faut évaluer selon une grille de manière régulière. En gros, on a pas le droit d’en perdre et de les laisser se noyer. Pour plus de sûreté et étant donnée le niveau de l’éducation nationale dans le domaine du numérique (en IUT en tout cas), on va rester sur de bonnes bases en natation mais peu de connaissances du grand large.

En effet, la formation est basée sur l’organisation de modules tel que le PHP, le CSS, le HTML, Photoshop, les CMS,… Ce qui peut être assez intéressant pour dissocier/faire comprendre les différents métiers et domaines mais qui est totalement contreproductif pour apprendre le web qui consiste à la réalisation complexe de tâches.

Ceci a pour effet qu’il est assez difficile d’approfondir un cas pratique (la gestion d’une grille dans tel CMS, utiliser github pour héberger un site statique), car cela mord sur le programme des autres cours (CSS, HTML ou Administration). Ainsi, on reste sybillin sur le grand large en restant sur l’exercice de sa discipline (faites moi dix longeurs).

Il existe quand même ce qu’on appelle des projets tutorés (cas réel de réalisation d’un site), ou des cas d’élèves en alternance, cependant la différence qualité de ces personnes ne va pas régler le problème d’homogénéité.

Conclusion

Le cursus en IUT n’est pas si mal pensé, mais je pense qu’il tient sur la capacité des entreprises ou professeurs à bien former nos futurs collaborateurs, c’est-à-dire avoir du temps. Sauf que d’un côté nous avons des professeurs qui ne connaissent peut-être pas suffisamment les processus de production et de l’autre côté des tuteurs qui n’ont pas beaucoup de temps pour former leurs stagiaires (et au milieu des vacataires).

Qu’on garde cette mise en place pour les 2 premières années de cursus d’IUT pour apprendre à maîtriser correctement le code, très bien. Mais on devrait peut-être faire évoluer le programme de licence pour être plus adapté à des élèves en bac+3. Ils n’ont plus vraiment l’âge d’être notés individuellement, ni de devoir faire leur gamme sur des exercices d’école. Mon avis est qu’il faut les pousser vers le monde professionel à travers l’apprentissage de méthodes de conception et de travail collaboratif.

En gros développer le mode de travail sous forme d’ateliers.

Transmettre le savoir, organiser des cours de web

21 jan 2015

Mon année 2014 s’est emballée à partir du mois de septembre, trop de contrats en parallèles et mes débuts comme professeur à l’IUT d’Elbeuf m’ont pris pas mal de mon temps. Pendant ces 3 heures de cours par semaine, j’ai pu expérimenter l’apprentissage de Git, de la struture de fichiers et de la conception web.

En juillet 2014, je suis appelé pour donner des cours à l’IUT d’Elbeuf en Licence Multimedia pour des cours de CMS/Ecommerce. En Septembre 2014, je reçois mon emploi du temps, sans préparation, sans modèle, sans guide, je suis jeté dans le bain.

Le programme original était d’apprendre à cliquer dans WordPress et d’installer un Prestashop. Étant donné la difficulté à installer des bases de données sur des machines sans droits administrateurs et surtout par choix personnel, j’ai entamé des cours sur la réalisation d’un tumblr, d’un site sous Git/Jekyll et une boutique shopify.

Je vais essayer de vous donner dans les billets suivants les retours sur quelques ateliers.

La précarisation des graphistes

25 nov 2014

Les évolutions des web en général et l’apparition de nouveaux types d’organisation pour la réalisation de produits ou d’applications web amène à une modification des structures relationnels entre nos métiers. Nous passons d’équipes web organisées autour de la publication d’informations (type agence) à de la conception de produits spécifiques (type startup).

La nécessité des realeases

La possibilité de développement de sites applicatifs (webapp) dans le navigateur a provoqué l’arrivé de prises de conscience de principes comme : le développement guidé par les tests, l’agilité ou encore le monitoring.

Le besoin de mise en production fréquente de modifications a petit à petit amené les intervenants à se familiariser avec ces notions. Les membres typiques d’une équipe de dev se doivent de maîtriser les commandes du terminal pour lancer des processus, versionner leur travail ou configurer une fonctionnalité.

Dans cette chaîne de participation, nous trouvons principalement les métiers du développement, intégrateurs, développeurs, sysadmin… mais peu de graphistes.

Le renversement de modèle

Dans une agence web, qui s’assimile parfois plus à une agence de communication, la mise en forme est très importante. On va vendre à un client un univers graphique et fonctionnel qui va le différencier de ses concurrents.
Dans ce système qui a prévalu entre les années 2000 et 2010, le graphiste est présent en avant vente, c’est lui qui va créer la « plus value » d’un site qui va permettre de se différencier d’un client (on l’appelle parfois designer).
Comme le visuel et la conception de ce visuel sont mis au centre, les autres métiers sont en quelques sortes relégués à la périphérie. Celui qui est le moins reconnu dans ce système est l’intégrateur ; dont le rôle se limite à la traduction de la composition graphique en code, il est en bout de chaine.

Dans une équipe de type développement applicatif en revanche, on va s’intéresser (en théorie) plus au domaine technique. On ne va pas forcément chercher à se différencier graphiquement mais plutôt chercher à améliorer le service proposé.

On se concentrera sur la modélisation technique et la manière dont on va stabiliser les développements. Ceci impliquant d’avoir du code qualité donc une personne compétente à chaque poste, donc un « développeur front » (qui peut-être dans certains cas un intégrateur).
L’objectif sera que chacun respecte au maximum les contraintes de la production afin de garantir la meilleure disponibilité de l’application.

La précarisation du graphiste

En raison de la complexité de développement d’une application, il est compréhensible que la réflexion sur le graphisme ne soit pas prioritaire. Par facilité, pour la partie interface, on passera par l’utilisation d’un Framework HTML/CSS, on développera une première version assez rapidement et en fonction des retours, on fera appel à un graphiste pour mettre un peu de couleur dans tout ça.

Or, vous le savez aussi bien que moi, l’équipe idéale doit comporter un certain nombre de compétences et la compétence graphique (UX) est aussi essentielle que les autres. Les équipe d’expérience pensent bien évidemment à valoriser ce métier.

Sauf que si dans un cas extrême de la boîte de communication c’est l’intégrateur qui a priori va être considéré comme le métier ayant le moins de valeur. Dans le cas d’une équipe d’application, c’est le graphiste qui va être déconsidéré.

Une question de compréhension

J’explique ce phénomène par le langage.

Dans une agence de communication, on va valoriser l’image. Le graphiste va particulièrement bien s’intégrer à ce milieu en terme de domaine. On parle de qualité visuel, de grain, d’émotions, de couleurs…
L’intégrateur est, dans ce domaine, une personne qui parle même langage mais mal car ce n’est pas sa formation et que son navigateur ne lui permet (permettait) pas de tout faire.

Dans une entreprise technique, on va parler disponibilité de contenus. Le langage sera basé sur la capacité à mettre à jour un dépôt de données et de savoir à quel moment on le transfert d’une plateforme à une autre.
Le graphiste est, dans ce domaine, une personne qui ne parle pas du tout le même langage que les autres. Il n’est pas intégré à la discussion sur la gestion de versions.

Sauvons les graphistes

C’est vrai que les besoins grandissant de conseils dans la conception d’interface donnent à une partie des intégrateurs une plus grande considération. C’est avec délectation que nous dirigeons les affaires et que, pour ma part, j’ai participé à l’éviction d’un (mauvais) graphiste sur un projet : « il est nul en web, on ne veut pas travailler avec lui ».
Vengeance !!!

Mais je ne crois pas que la dominance d’un métier sur un autre permette de prendre plaisir au travail et de réaliser des interfaces de qualité.
Il faut prendre donc conscience que si on a des exigences, il faut inciter le maximum de compétences à échanger leurs points de vue.

Pour cela, il faut que tout le monde parle le même langage. La formation de la plupart des graphistes ne leur apprend pas les contraintes techniques du web. Ils ont donc énormément de mal à savoir comment et à quel moment participer à l’amélioration des interfaces.

Sauvons les graphistes

Pour cela :

  1. Imposons des réunions de co-création multicompétence en amont de projet
  2. Réfléchissons à quelle peut-être l’utilité de Git pour un graphiste
  3. Mettons en place des cours pour former les graphistes à Git

Les budgets miroirs

15 oct 2014

La relation client reste une sorte de maîtrise empirique de la manière dont on arrive à vendre une réalisation pour une certaine somme. Personnellement, je tente au maximum de réduire au maximum l’enveloppe et le périmètre afin d’être sûr que mon interlocuteur garde de la réserve pour des évolutions ou des corrections.

Le mode projet

Vous connaissez les chefs de projets ? Maintenant, demandez à un de vos chef de projets de vous définir ce qu’est un projet.

Je donne ma main à couper que 98% de ceux-ci ne sont pas capables de vous donner une définition juste de ce que le mot projet relève. Si on se réfère à wikipédia, on trouve :

Le fonctionnement en « mode projet » se distingue du fonctionnement en mode processus en ce sens qu’une activité conduite en mode projet n’est généralement pas destinée à être répétée : son côté « inédit et unique » souligne la probabilité d’être confronté à un environnement incertain, du fait de l’absence plus ou moins grande d’expériences ou de pratiques antérieures. Par ailleurs, un processus est destiné à durer et n’a pas, en général de date de fin prévue.

Le mode projet est « inédit et unique », il n’est pas destiné à être répété, il s’oppose au mode processus.

Le mode processus

La définition du mode processus :

Un processus est un ensemble d’activités corrélées ou interactives qui transforme des éléments d’entrée en éléments de sortie. Ces éléments sont soit des objets matériels (pouvant être perçus comme des flux par la logistique à des fins d’évaluation) soit des informations, soit les deux.

Le mode processus permet de transformer des informations en d’autres informations : un cahier des charges en pages HTML par exemple.

Un projet web

Il semble que l’inculture généralisée sévit dans les équipes web. Certains de transformer le monde et de participer à un avenir radieux, plutôt que de garder un regard cohérent sur sa situation, chacun se donne des « airs » en prenant pour un statut de poste le plus valorisant.
Nous connaissons d’ailleurs le ridicule de celui de chef de projets ; une personne qui ne dirige pas des hommes mais ces choses très immatériels que sont des projets.

Pour commencer à défricher le sujet admettons que le projet web ne désigne rien de précis et commençons par distinguer 2 choses : le mode projet (le développement) et le mode processus (la maintenance et édition du site).

Les budgets miroirs

Puisque nous savons tous qu’un « projet » rentable est avant tout un « projet » bien vendu. Posons seulement la question de ce qui est vendu lors d’un développement.

Comme nous pensons tous « projets » (transformation du monde), au moment de discuter budget, tout le monde parle du budget de transformation.

Ne vous êtes vous jamais dit : cette fonctionnalité ne sert à rien, cette fonctionnalité ne sera jamais utilisé… le client aurait mieux fait d’investir autrement.

On parle d’agilité, de manière de vendre, de saucissonnage en sprint ; mais avez vous seulement effectué cette opération simple : mettre en regard le budget de transformation avec le budget de maintenance.

Le budget de maintenance est le budget qui sera nécessaire pour faire vivre le site, améliorer des fonctionnalités, communiquer…

Essayer de présenter d’un côté les fonctionnalités que désire votre client et ce qu’il faudra qu’il débourse pour faire vivre le site : un salaire de rédacteur, un budget de maintenance avec vous…

A priori, si vous arrivez à présenter à votre client la gestion de son site avec une vision stratégique pour qu’il dure dans le temps, il est fort possible que vous arriviez soit à faire baisser la voilure du projet initial pour qu’il se concentre sur ce qui a de la valeur ou à mettre plus d’argent afin que les développements rentre dans un processus élargie d’édition de contenus.


© Copyright 2009 bertrandkeller . Merci pour la visite