Comprendre avant de construire

Il est presque deux heures du matin. C’est souvent à cette heure-là, quand le téléphone se tait et que les messages cessent d’arriver, que l’on voit le plus clairement ce qui ne va pas dans notre métier.

Je repense à une scène que tout développeur connaît. Un projet commence. Le client a une idée, une vraie, de celles qui le tiennent éveillé lui aussi. Il nous l’envoie. Mais il nous l’envoie en morceaux : un premier email qui pose le décor, un deuxième avec trois captures d’écran, un message vocal sur une messagerie, un PDF « plus complet » quelques jours plus tard, un lien vers un dossier partagé où dort une maquette, puis ce dernier message que nous connaissons tous : « Ah, et j’avais oublié… »

Chacun de ces morceaux est sincère. Aucun n’est faux. Et pourtant, celui qui doit construire le projet n’a jamais l’ensemble sous les yeux. Il doit le recomposer dans sa tête, comme on reconstitue un vase à partir de tessons dispersés dans plusieurs pièces de la maison. Il y parvient, parfois. Mais ce qu’il reconstruit n’est jamais tout à fait ce que le client avait imaginé. C’est une copie faite de mémoire.

STRUKTUR est né de cette scène. Pas d’une ambition technique, pas d’une envie d’ajouter un outil de plus à la liste déjà trop longue des outils que l’on impose aux gens. Il est né d’une question simple, presque naïve : et si l’idée arrivait entière ?

Tout projet numérique vit dans un écart. D’un côté, ce que le client imagine. De l’autre, ce que l’équipe comprend. Entre les deux, il y a un espace que l’on remplit, faute de mieux, avec des réunions, des comptes rendus, des allers-retours, des « pour être sûr d’avoir bien compris », des versions successives qui corrigent les malentendus des versions précédentes.

On a pris l’habitude d’appeler cela le processus. On l’a outillé, normé, découpé en étapes. On lui a donné des noms rassurants. Mais à bien y regarder, une grande part de ce processus n’est rien d’autre que le coût de l’écart : le prix que l’on paie, en temps et en patience, parce que l’idée n’a pas voyagé correctement d’une tête à l’autre.

Je crois que c’est là que se jouent la plupart des échecs de projets. Rarement dans le code. Le code, nous savons l’écrire. Les échecs naissent plus tôt, dans ce territoire flou où personne n’est vraiment responsable de la compréhension. Le client pense avoir été clair, puisqu’il a tout dit. L’équipe pense avoir compris, puisqu’elle a tout lu. Les deux ont raison, et pourtant le résultat déçoit.

Réduire cet écart, voilà le vrai sujet. Pas le stockage des fichiers, pas la gestion de projet au sens administratif du terme. La compréhension. Tout le reste en découle.

Un projet échoue rarement dans le code. Il échoue avant, dans la distance entre ce que l’on imagine et ce que l’autre comprend.

Face à cet écart, notre secteur a souvent répondu par le formulaire. Un cahier des charges type, une liste de champs à remplir, des cases à cocher : nom du projet, objectifs, public cible, fonctionnalités souhaitées, budget, délais. L’intention est louable. On veut que rien ne manque. On veut structurer.

Mais le formulaire exerce une violence douce. Il demande à celui qui a une idée de penser comme une base de données. Il découpe sa pensée avant même qu’elle ait pu se former. Il impose un ordre qui n’est pas le sien, des catégories qui ne sont pas les siennes, et il punit ce qui déborde : la nuance, l’hésitation, l’exemple, l’intuition. Ce qui fait la singularité d’un projet est précisément ce qui ne rentre dans aucun champ.

Une personne qui imagine une plateforme ne pense pas en rubriques. Elle pense en récit. Elle commence par ce qui l’anime, s’arrête sur un détail qui lui tient à cœur, revient en arrière, montre une image parce qu’un mot ne suffit pas, se souvient d’une application qu’elle aime, précise une contrainte, dit à voix haute ce qu’elle n’arrive pas à écrire. Sa pensée a une forme. Le formulaire la lui retire.

C’est ce que j’appelle un process lourd. Pas forcément un process long : un process qui oblige l’humain à se plier à l’outil plutôt que l’inverse. Chaque champ obligatoire est une petite exigence. Chaque étape de validation, une petite attente. Prises une à une, elles semblent raisonnables. Additionnées, elles découragent, fatiguent, et finissent par produire exactement ce qu’elles voulaient éviter : des informations incomplètes, données à contrecœur.

STRUKTUR refuse le formulaire. Il n’y a pas de champ à remplir. Il y a une page.

Une page, donc. Un titre, que l’on choisit soi-même. Puis l’on écrit.

On écrit comme on parlerait à quelqu’un de confiance. Une introduction, si l’on veut. Un grand titre pour marquer une partie. Un sous-titre pour une nuance. Du gras pour ce qui compte vraiment, une liste quand les idées s’énumèrent, un lien vers ce qui inspire. Rien de plus : nous avons volontairement gardé une écriture simple, parce que l’objectif n’est pas de produire une mise en page, mais de transmettre une pensée.

Et quand les mots ne suffisent plus, on ajoute autre chose, à l’endroit exact où l’on en a besoin :

• une image : la capture d’un site que l’on admire, une photo, une maquette griffonnée ;
• un message vocal, enregistré sur place, parce qu’il est parfois plus juste d’expliquer de vive voix comment une page doit se comporter ;
• un document : la charte graphique, l’étude, le cahier des charges qui existait déjà ;
• un son : le jingle de la marque, une musique de référence, une voix off ;
• un fichier de logiciel : le PSD du logo, la présentation, la première maquette dessinée dans un outil de création.

Puis on reprend l’écriture. Et l’on recommence.

Il y a dans ce geste quelque chose de très ancien. C’est celui du carnet d’atelier, de l’architecte qui annote ses croquis, de l’artisan qui colle un échantillon de tissu à côté de sa note. La pensée créative n’a jamais été purement textuelle. Elle mêle le mot, l’image, la voix, l’objet. Les outils numériques l’avaient fragmentée en applications séparées : le texte ici, les images là, les vocaux ailleurs, les fichiers dans un autre service encore. STRUKTUR la recoud.

Pour celui qui écrit, la mécanique reste invisible. Derrière chaque paragraphe, chaque image, chaque vocal, il y a un bloc, avec sa place, son type, son histoire. Mais le client n’en voit rien, et c’est voulu. Il ne manipule pas des blocs. Il écrit, il ajoute quelque chose, il continue. La technique est au service du geste, jamais l’inverse.

J’écris, j’ajoute quelque chose, je continue. Toute la promesse tient dans cette phrase.

Il y a une différence immense, et pourtant rarement nommée, entre recevoir dix-sept fichiers et recevoir dix-sept éléments placés dans une réflexion.

Dix-sept fichiers, c’est une pile. On les ouvre un par un, on devine leur rôle, on se demande lequel est le plus récent, lequel n’était qu’une piste abandonnée. Le sens de chaque fichier est resté dans la tête de celui qui l’a envoyé.

Dix-sept éléments placés dans une réflexion, c’est un discours. L’image d’inspiration se trouve juste sous la phrase qui dit pourquoi elle inspire. La charte graphique suit le paragraphe qui précise ce qu’il faut en garder et ce qu’il faut oublier. Le vocal arrive au moment où le client explique le fonctionnement d’une page, et il l’éclaire. Chaque élément porte avec lui son contexte, parce qu’il est posé à l’endroit où il a du sens.

C’est pour cela que l’ordre est sacré dans STRUKTUR. Si le client écrit, puis montre une image, puis écrit encore, puis joint un document, l’équipe lit exactement dans cet ordre. Nous ne rangeons pas les textes d’un côté et les images de l’autre : ce serait détruire la pensée pour classer les fichiers. Et si le client veut réorganiser son propos, il déplace simplement un bloc, comme on déplace un paragraphe dans un brouillon.

Le contexte n’est pas un supplément d’information. Il est la matière même du projet. Un fichier sans contexte est une énigme ; un fichier dans son contexte est une explication.

Un document vivant pose une question que les formulaires évitaient : que se passe-t-il quand on se trompe ?

Car on se trompe. On efface un paragraphe en pensant qu’il ne sert plus. On remplace une image par une autre. On réécrit une partie un soir de fatigue. Si l’outil enregistre tout, tout le temps, il faut qu’il protège aussi contre soi-même.

STRUKTUR enregistre sans qu’on le lui demande. Il n’y a pas de bouton « Enregistrer » : chaque mot part tout seul, après une courte pause dans la frappe. Mais nous avons tenu à une règle d’honnêteté : rien n’est annoncé comme enregistré tant que le serveur ne l’a pas réellement accepté. Si la connexion tombe, ce qui a été écrit reste conservé sur l’appareil et repart dès qu’elle revient. On peut fermer l’application au milieu d’une phrase. On retrouvera la phrase.

Et le document se souvient. Au fil du travail, il garde des versions de lui-même ; on peut aussi en marquer une, lui donner un nom, comme on date un brouillon important. Revenir en arrière ne détruit rien : avant chaque restauration, l’état présent est lui-même conservé. Retirer un bloc ne fait pas disparaître le fichier qu’il portait : une version antérieure peut encore y renvoyer.

Il y a là, je crois, une forme de respect. Respect du temps de celui qui a écrit. Respect du droit à l’hésitation, qui est le droit de tout esprit qui cherche. Un outil qui fait perdre un texte apprend à ses utilisateurs à ne plus rien confier. Un outil qui ne perd rien les invite à tout dire.

Rien n’est détruit en silence. C’est la condition pour que l’on ose tout écrire.

Au premier regard, on pourrait croire que STRUKTUR est l’espace du client, et que l’équipe se contente de le lire. Ce serait manquer l’essentiel.

Un projet se comprend à deux. Le client apporte la vision ; l’équipe apporte les questions qui la rendent réalisable. STRUKTUR accueille donc les deux voix dans le même document. L’équipe peut y écrire à son tour, ajouter un plan, une image annotée, une reformulation : « Voici comment nous avons compris votre besoin. » Le client voit ce que l’équipe a ajouté, signalé comme une nouveauté.

Et quand une précision porte sur un point précis, elle s’y accroche. Chaque bloc peut recevoir ses commentaires : une question de l’équipe sous la phrase qui la suscite, une réponse du client juste en dessous. La discussion ne s’échappe pas dans un fil séparé où l’on perdrait le lien avec ce dont on parle. Elle reste attachée à son objet.

Ce n’est pas une messagerie. C’est un document qui se densifie à mesure que deux intelligences s’y rencontrent. L’image me semble juste : la compréhension n’est pas un message que l’on envoie, c’est un texte que l’on écrit ensemble.

Dans AJT Connect, STRUKTUR ne vit pas seul. Il partage l’onglet AJTOOL avec AJTASK, et cette cohabitation dit beaucoup de notre manière de penser le travail.

AJTASK répond à une phrase : « Fais ceci. » Changer un bouton, remplacer une image, corriger un texte. Une demande, un cycle, une clôture. On envoie une ligne, un vocal, une photo, et l’on suit le traitement jusqu’à la réponse de l’équipe. C’est l’outil de l’exécution.

STRUKTUR répond à une autre phrase : « Comprends ceci. » Voici mon projet, son intention, son public, son identité, ses références. Ce document ne se termine pas comme une demande se termine : il accompagne le projet tant que le projet vit. C’est l’outil de la compréhension.

Les deux ne se confondent pas, et c’est voulu. Mélanger la conception et l’exécution, c’est noyer la vision dans les tâches, ou retarder les tâches au nom de la vision. Les séparer, c’est rendre à chacun son rythme. On comprend d’abord. Puis, une fois le projet compris, on revient à AJTASK : « Maintenant, faisons ceci. »

Chaque commande reçoit d’ailleurs son propre STRUKTUR, rattaché à elle et identifié par son code. Le projet n’est jamais un espace flottant, déconnecté de ce qui a été commandé : il a une adresse, un contexte, un lieu où tout se retrouve.

AJTASK dit : fais ceci. STRUKTUR dit : comprends ceci. Le bon travail se fait dans cet ordre.

Confier son projet, c’est confier une part de soi. Les idées d’un client sont souvent ce qu’il a de plus précieux et de plus fragile : un futur produit, une stratégie, l’identité d’une marque qui n’existe pas encore. On ne peut pas lui demander de tout déposer dans un espace sans lui garantir que cet espace est sûr.

Cette confiance ne se décrète pas ; elle se construit, et elle se construit en grande partie là où personne ne regarde. Les fichiers déposés dans STRUKTUR ne sont jamais exposés par leur emplacement : ils ne sortent de leur coffre que par des liens temporaires, accordés à la personne autorisée. Le nom affiché d’un fichier peut changer ; son nom réel sur nos serveurs, lui, ne se devine pas et ne se choisit pas. Chaque type de fichier est vérifié. Rien de ce qui s’écrit dans un STRUKTUR n’est public : cela reste entre le client et l’équipe.

Je tiens à ce que cette sécurité soit invisible pour celui qui écrit. Un outil qui demande sans cesse de penser à la sécurité finit par devenir lui-même un process lourd. La vraie protection est celle que l’on n’a pas à gérer.

On me demande parfois si STRUKTUR n’est qu’une commodité de plus. Je crois qu’il est davantage : une prise de position sur la manière dont les entreprises informatiques devraient travailler avec leurs clients.

Notre métier s’adresse à des personnes qui ont des besoins applicatifs, qui attendent un logiciel métier taillé pour leur activité, ou qui engagent la transformation numérique de leur entreprise. Ces personnes ne sont pas des spécialistes de notre langage, et elles n’ont pas à le devenir. Pourtant, nous leur demandons trop souvent de traduire elles-mêmes leurs idées dans nos catégories, nos formats, nos procédures. Nous déplaçons vers elles la charge de la compréhension.

STRUKTUR inverse ce mouvement. Il laisse le client s’exprimer dans sa forme naturelle, et c’est à nous, l’équipe, de faire le travail de compréhension, avec les questions, les commentaires, les reformulations. Le document devient le lieu où ce travail se voit, se trace, se partage. Quand un nouveau membre rejoint l’équipe, il ne reconstitue plus le projet à partir d’une archive d’emails : il lit le STRUKTUR, dans l’ordre où la pensée s’est construite. Et si l’équipe a besoin d’une trace figée, elle peut en tirer un document à imprimer.

La transformation numérique est souvent racontée comme une affaire d’outils. Je pense qu’elle est d’abord une affaire de compréhension. Une entreprise qui se transforme a besoin d’être entendue avant d’être équipée. Commencer par un espace où elle peut tout dire, à sa façon, c’est commencer par le bon bout.

Une entreprise qui se transforme a besoin d’être entendue avant d’être équipée.

« Plus jamais de process lourds. » C’est la première phrase que l’on lit en découvrant AJT Connect. On pourrait la prendre pour un slogan. Je la lis comme un engagement, et je veux dire ce qu’il recouvre.

Plus jamais de process lourds (No more heavyweight processes) : cela ne signifie pas l’absence de rigueur. Au contraire, la rigueur est déplacée là où elle doit être. Dans l’outil, qui enregistre, protège, ordonne et se souvient. Pas dans l’humain, qui doit pouvoir penser librement.

Cela signifie qu’une idée doit pouvoir être confiée telle qu’elle est née, avec ses mots, ses images, sa voix. Qu’aucune information ne doit se perdre entre deux messages. Que le client ne doit jamais avoir l’impression de remplir un dossier administratif pour obtenir le logiciel dont il rêve. Que l’équipe ne doit jamais avoir à deviner ce qu’on ne lui a pas montré.

Il est presque deux heures du matin, et je reviens à la scène du début. Le développeur, ses emails, ses captures dispersées, son vocal égaré, son « j’avais oublié ». Je ne crois pas qu’il soit possible de supprimer entièrement l’écart entre deux esprits. Mais je crois qu’il est possible de le réduire bien davantage que nous ne l’avons fait jusqu’ici. Il suffit de cesser de demander aux gens de penser comme nos outils, et de construire enfin des outils qui pensent comme les gens.

C’est ce que nous avons essayé de faire avec STRUKTUR. Comprendre avant de construire. Et construire, enfin, ce qui a été compris.