Comment se déroule la création d’un site ou d’une application

Tout commence par le problème, pas par la technologie. Que doit accomplir le site ou l’application ? Qui va l’utiliser, et que cherche à faire cette personne en arrivant ? Qu’est-ce qui existe déjà — un nom de domaine, un ancien site, un logo, des textes, des photographies, un tableur que quelqu’un tient depuis des années ? Et qu’est-ce qui doit être prêt en premier ?

Un ou deux exemples de sites qui vous plaisent en disent plus qu’un long cahier des charges. Ils n’ont pas besoin d’être de votre secteur. Parfois, ce qui est utile, c’est le rythme calme d’une page, parfois la façon dont un menu est organisé, parfois seulement une couleur. Je vous demande ce qui vous plaît exactement, car c’est cette partie-là que l’on peut reprendre.

C’est aussi au cours de cet échange que je dis ce que je ne construirais pas. Si une solution plus simple fait l’affaire, mieux vaut l’entendre au début que le découvrir après la mise en ligne.

À partir de cet échange, je propose un périmètre réaliste et je le découpe en phases. La première phase est la plus petite version qui remplit la fonction principale : pour une poissonnerie comme Ihtis, au marché central de Banja Luka, cela signifiait un chemin clair entre l’offre du jour et une commande via Viber, pensé pour être confortable sur un téléphone.

Les produits plus importants grandissent par étapes. Omaška, un système en ligne pour un cabinet privé de psychiatrie et de psychothérapie, relie la prise de rendez-vous, les dossiers des patients, les documents, la facturation en KM et un portail patient. Un produit de ce type ne se conçoit pas d’un seul coup ; chaque partie se construit sur la précédente.

Le prix et les délais découlent du périmètre : ils se décident donc après cette étape, plutôt que d’être devinés avant. Un chiffre donné avant que quiconque sache ce qui sera construit n’est pas une promesse, c’est une supposition.

Je peux travailler à partir d’un design existant, améliorer des esquisses ou concevoir l’interface au fil du développement. En pratique, la plupart des projets mélangent les trois : certains écrans sont clairs dès le départ, d’autres ne le deviennent qu’une fois le vrai contenu en place.

Vous voyez le travail tôt, dans un navigateur et sur votre propre téléphone, au lieu d’attendre une série d’images terminées. Une image de site cache les questions qui comptent : la longueur réelle du texte, le comportement d’une page sur un petit écran, ce qui se passe quand une photographie manque.

L’accent est mis sur des parcours clairs, la hiérarchie visuelle et les détails qui donnent à un produit un aspect abouti. Quand une entreprise n’a pas encore d’identité, cela peut faire partie du travail — le signe, la typographie et la couleur sont conçus en même temps que l’interface, et non livrés à part.

Le frontend, le backend, la base de données et les intégrations sont construits ensemble, comme un seul système. Je travaille surtout avec React et Next.js pour le web, React Native pour le mobile, et Node.js avec une base de données relationnelle derrière, mais la technique suit le problème et non l’inverse.

La logique métier — les prix, les réservations, les autorisations, qui peut voir quel document — est écrite de façon à ce que l’on sache clairement où elle se trouve et comment la modifier. C’est plus important qu’il n’y paraît : le jour où une grille tarifaire ou un horaire change, quelqu’un doit pouvoir le mettre à jour sans qu’un développeur fouille tout le projet.

Les intégrations font partie du même travail : paiements, calendriers, e-mails, cartes, stockage de fichiers, ou un modèle d’IA lorsqu’il est réellement utile. Chacune est une dépendance, et chacune doit donc mériter sa place.

Le contenu est ce qui retarde le plus souvent une mise en ligne. Les textes, les photographies, les listes de produits et les prix vivent généralement dans la tête des personnes qui gèrent l’entreprise, pas dans un dossier prêt à être transmis.

Je vous aide à lui donner forme : ce qu’une page doit dire, dans quel ordre, et à quel point elle peut être courte. De bonnes photographies du vrai lieu, du vrai produit ou des vraies personnes font plus que n’importe quelle image de banque d’images, et quand les photos de produits sont le point faible, il existe des moyens de rendre un catalogue homogène.

Si un site doit être mis à jour souvent, il dispose d’un moyen simple de le faire — un CMS ou un panneau d’administration — pour que les modifications ne dépendent pas de moi.

Un projet se passe mieux quand personne ne se demande où il en est. Vous recevez tôt un lien vers le travail en cours, mis à jour au fil du développement, pour l’ouvrir sur votre téléphone quand vous le souhaitez, au lieu d’attendre une réunion.

Les retours fonctionnent mieux quand ils sont précis et réunis au même endroit : ce titre est trop long, cette photographie n’est pas la bonne, un client poserait cette question ici. Dix remarques courtes et claires font avancer un projet davantage qu’un long appel où l’on parle de tout sans rien noter.

Les décisions qui modifient le périmètre — une nouvelle fonctionnalité, une deuxième langue, une intégration non prévue — sont nommées comme telles dès qu’elles apparaissent. Ce sont souvent de bonnes idées ; elles appartiennent simplement à une phase, et il doit être clair laquelle.

Avant la mise en ligne, je passe en revue l’affichage sur différents écrans, les parcours principaux et les cas limites courants : un panier vide, un nom très long, une connexion lente, un formulaire envoyé deux fois.

Je vérifie la vitesse et les bases que lisent les moteurs de recherche : titres, descriptions, intertitres, descriptions des images, un sitemap et les versions linguistiques de chaque page. Ce n’est pas un service à part ajouté à la fin ; cela fait partie de la construction correcte d’un site.

Le déploiement lui-même est configuré et testé avant que le domaine ne pointe vers lui, pour que la bascule soit un moment tranquille plutôt qu’un événement.

La remise explique comment le projet fonctionne, où se trouve la logique essentielle et ce qu’il faut surveiller après la mise en ligne. Vous devriez être propriétaire de votre nom de domaine, de vos comptes d’hébergement et du code, et savoir où se trouve chacun d’eux.

Certains projets s’arrêtent là. D’autres continuent : Golden Standard, une marque et un système numérique pour trois marchés, est un travail en cours via Studio Blink — identité, site, CMS, plateforme B2B, programmes partenaires et studio de documents, développés pas à pas.

Les premières semaines après la mise en ligne sont le test le plus honnête. Les vrais visiteurs trouvent les questions auxquelles personne n’avait pensé, et le site doit s’adapter à ce qu’ils font réellement.

Ce que vous faites et pour qui, et ce que le site doit amener un visiteur à faire : appeler, réserver, commander, écrire. Un ou deux sites qui vous plaisent et un qui ne vous plaît pas.

Les textes et les photographies que vous avez déjà, même bruts, et l’accès au nom de domaine s’il existe. Avec cela, le premier échange peut aller directement aux décisions qui comptent.