Cookies necessaires
Toujours actifs. Ils assurent le fonctionnement technique du site et la memorisation de votre choix de consentement.
Un projet front-end ne commence pas avec npm install.
Il commence bien avant.
Quand on essaie de comprendre ce que l’on doit construire, pour qui, avec quelles contraintes et surtout avec quel niveau de finition.
Et c’est souvent là que se joue une bonne partie de la réussite du projet.
Après plusieurs années passées sur des sites web, applications métier, interfaces Angular, back-offices et plateformes plus complexes, j’ai constaté une chose assez simple :
Beaucoup de problèmes que l’on rencontre pendant le développement existaient déjà avant la première ligne de code.
Maquettes incomplètes, fonctionnalités mal définies, API pas prêtes, comportements mobiles oubliés, estimation faite trop tôt…
Puis quelques semaines plus tard arrive la fameuse question :
« Pourquoi le front prend plus de temps que prévu ? »
Parfois, la réponse se trouve simplement dans le cadrage initial.
Avant de choisir une architecture ou de découper les composants, il faut déjà comprendre le produit.
Cela paraît évident.
Pourtant, on commence encore régulièrement des projets avec une liste de fonctionnalités très générale :
« Il faut un espace utilisateur. »
« Il faut une recherche. »
« Il faut permettre de déposer un document. »
Sur le papier, tout paraît simple.
Mais derrière « une recherche », il peut y avoir :
Le premier travail consiste donc à clarifier quelques questions simples :
Définir ce qui est hors périmètre est presque aussi important que définir ce qui est dedans.
Parce que le fameux :
« On pourrait juste ajouter ça aussi… »
a parfois une étrange capacité à se multiplier pendant un projet.
Une maquette peut être magnifique dans Figma et pourtant laisser beaucoup de questions ouvertes côté développement.
Le desktop est prêt.
Très bien.
Et sur mobile ?
Que se passe-t-il lorsque le titre fait trois lignes ?
Quand la liste est vide ?
Quand l’API met deux secondes à répondre ?
Quand une erreur se produit ?
Quand un bouton est désactivé ?
Quand un utilisateur n’a pas les mêmes droits qu’un autre ?
Ce sont ces petits détails qui deviennent ensuite de vraies décisions front-end.
Avant de commencer l’intégration, j’aime donc vérifier que les principaux états de l’interface sont suffisamment clairs :
Cela ne veut pas dire que chaque pixel doit être figé avant le développement.
Un projet évolue forcément.
Mais il faut au minimum avoir une vision commune du comportement attendu.
Une maquette représente une interface. Elle ne décrit pas toujours tout son fonctionnement.
Et c’est précisément là que les échanges entre UX/UI, développeurs et chef de projet deviennent importants.
Certains sujets sont parfois considérés comme secondaires au début du projet.
Ils deviennent pourtant très importants quelques semaines plus tard.
Par exemple :
La réponse peut complètement changer certaines décisions techniques.
Prenons l’accessibilité.
Si elle est intégrée dès le départ, elle influence naturellement le HTML, les composants, la navigation clavier, le focus et les formulaires.
Si elle arrive à la fin sous la forme :
« Au fait, il faut aussi que le site soit accessible. »
la situation devient légèrement plus sportive.
Même chose pour le SEO, la performance ou le responsive.
Ce ne sont pas des couches de peinture que l’on ajoute deux jours avant la mise en production.
Ce sont des contraintes de conception.
Il existe une question que beaucoup de développeurs connaissent :
« Tu penses qu’il faut combien de temps pour faire le front ? »
Avec parfois trois écrans Figma et une description de six lignes.
Estimer un projet dans ces conditions ressemble un peu à estimer la durée d’un voyage en connaissant seulement la destination.
Avant de parler de jours ou de semaines, il faut découper.
Par exemple :
pages → fonctionnalités → composants → interactions → cas particuliers → dépendances
Une page de tableau de bord peut sembler être « une page ».
Mais elle peut contenir :
Le découpage permet de rendre le travail visible.
Il permet également d’identifier les dépendances.
Si le front dépend d’une API qui n’est pas encore disponible, ce n’est pas forcément bloquant.
On peut travailler avec des mocks.
Mais il vaut mieux le savoir au début que le découvrir lorsque l’intégration doit commencer.
Une estimation devient beaucoup plus fiable lorsqu’on estime des éléments compréhensibles plutôt qu’un énorme bloc appelé :
« Faire le front. »
C’est probablement l’un des points les plus simples à mettre en place.
Et pourtant, il évite beaucoup de malentendus.
Quand considère-t-on qu’une fonctionnalité est terminée ?
Lorsque l’intégration ressemble à la maquette ?
Lorsque l’API est branchée ?
Lorsque cela fonctionne sur mobile ?
Lorsque les erreurs sont gérées ?
Lorsque les tests sont passés ?
La réponse doit être claire pour toute l’équipe.
Pour une fonctionnalité front-end, « terminé » peut par exemple signifier :
La liste dépend évidemment du projet.
Mais l’essentiel est que tout le monde parle de la même chose.
Parce qu’entre :
« J’ai fini le développement »
et
« La fonctionnalité est prête pour la production »
il peut parfois rester quelques kilomètres de route.
Lorsque les délais sont serrés, on peut être tenté de commencer immédiatement le développement.
Cela donne l’impression d’avancer plus vite.
Mais prendre un peu de temps au départ pour poser les bonnes questions permet souvent d’éviter beaucoup d’allers-retours ensuite.
Le cadrage n’a pas besoin de devenir une énorme documentation.
Quelques échanges efficaces, des maquettes suffisamment complètes, un découpage clair et des responsabilités bien identifiées peuvent déjà faire une grande différence.
Le but n’est pas de prévoir absolument tous les problèmes.
C’est impossible.
Le but est surtout de supprimer le maximum de zones floues avant qu’elles ne deviennent des problèmes techniques.
Car au final, un bon projet front-end ne commence pas par écrire du code.
Il commence par s’assurer que toute l’équipe essaie de construire le même produit.