Crealead — portail coopératif : conception et prototype

Crealead — portail des co-entrepreneurs : conception et prototype

Coopérative d’entrepreneurs. Mission de conception de son portail interne. Le livrable est un prototype navigable et un langage visuel, destinés à être confrontés à de vrais membres avant tout développement. Aucune application déployée, aucun code livré — et c’est précisément l’intérêt de la mission.

Secteur : services aux entreprises
Rôle : conception amont, prototype et langage visuel
Statut : mission terminée, aucun code livré

Le contexte

Une coopérative d’entrepreneurs rassemble des indépendants qui partagent une structure juridique et des services. Son portail interne doit faire tenir ensemble des choses qui ne se ressemblent pas : des outils, des documents, une vie collective, et des gens qui ne se connaissent pas mais gagneraient à se connaître.

La difficulté n’est pas de dessiner des écrans. Elle est de trancher ce que le portail est : un intranet de documents auquel on a ajouté un annuaire, ou un lieu où l’on se trouve les uns les autres et où les documents sont à côté. Les deux réponses produisent la même liste de fonctionnalités et deux produits différents.

Voilà pourquoi cette mission s’arrête avant le développement, et pourquoi ce n’est pas une version économique du vrai travail. Dans une maquette, un bloc se déplace. Une fois développé, il faut le défaire — et défaire coûte toujours plus que déplacer. Un architecte qui commence par écrire du code s’interdit de changer d’avis, au moment précis où changer d’avis est encore gratuit.

Le périmètre, dit précisément

La mission s’arrête volontairement avant le développement. Ce qu’elle produit — une structure tranchée devant de vrais membres — est ce qui coûte le plus cher à corriger après.

Une précision qui appartient au lecteur plutôt qu’à moi : je suis moi-même co-entrepreneur de cette coopérative. Animer son pôle numérique et avoir conçu son portail sont deux choses différentes ; la première appartient à mon parcours, la seconde est cette fiche.

Les décisions

Faire de l’annuaire une carte, et de la carte la page d’accueil.

Un annuaire alphabétique répond à la question « où est le dossier de cette personne ». Il ne répond pas à celle que les membres se posent réellement : qui, autour de moi, fait quelque chose qui me concerne.

La structure retenue place donc la carte des membres en entrée, et les documents à côté. Ce n’est pas un choix esthétique : il décide de ce que le portail encourage. Une page d’accueil qui liste des fichiers produit un outil qu’on ouvre quand on a besoin de quelque chose ; une page qui montre des personnes produit un lieu où l’on passe.

Trancher devant de vrais membres, pas devant un comité.

Le prototype est navigable. Il n’illustre pas la structure, il la fait éprouver : on clique, on se perd, et on découvre à quel endroit précis on s’est perdu.

C’est la seule manière que je connaisse de départager deux structures également défendables sur le papier. Un comité arbitre sur des arguments ; un membre qui cherche quelque chose arbitre sur ce qu’il trouve.

Livrer un langage visuel plutôt que des écrans finis.

Des écrans finis se périment à la première fonctionnalité non prévue, et l’équipe qui développera devra inventer le reste sans savoir si elle reste cohérente.

Un langage — les composants, leurs états, ce qu’ils signifient et quand on les emploie — se prolonge. Il coûte plus cher à produire et il survit à la mission, ce qui est exactement le critère.