Bouhnik Expertises

Webcam Immobilier est une SARL créée en avril 2003, installée au 14 avenue des Broussailles à Cannes. Davy Bouhnik la dirige depuis janvier 2005 et il y travaille seul. C'est une agence membre de la FNAIM, positionnée à 100 % sur la transaction : ni location, ni gestion locative, ni syndic. Tout le temps passe sur la vente des biens qu'on lui confie et sur la recherche pour les acquéreurs qui le mandatent. Elle couvre Cannes, Le Cannet, Mougins, Mandelieu-la-Napoule et l'arrière-pays cannois, avec une quarantaine de biens au portefeuille.

Le marché sur lequel elle opère est cher et tendu. À l'été 2026, le mètre carré à Cannes se situe autour de 5 800 à 6 100 € selon les baromètres des grands portails immobiliers, avec un écart net entre les appartements, autour de 5 800 €, et les maisons, autour de 6 900 €. À l'échelle du département, la chambre des notaires des Alpes-Maritimes relève une hausse de 2,4 % sur un an dans l'ancien : une progression mesurée, après plusieurs années de variations beaucoup plus brutales. Sur un marché pareil, une agence d'une seule personne ne se distingue pas par le volume qu'elle traite, mais par ce qu'elle sait faire que les autres ne savent pas. C'est exactement ce que la seconde activité de Davy apporte — et ce que le site devait rendre visible.

À côté de l'agence, Davy exerce une seconde activité en entreprise individuelle : l'expertise. C'est celle-là qui a fait l'objet de mon stage, et les deux se répondent — l'activité déclarée de l'agence mentionne d'ailleurs l'expertise immobilière à côté de la transaction. Il est expert en pathologie du bâti et en valeur vénale, membre de l'Institut International des Experts au sein du réseau Les Experts Vauban, et chargé d'enseignement à l'Université Toulouse Capitole. Plus de vingt-cinq ans d'expérience dans l'immobilier.

Le marché de l'expertise est particulier, et c'est lui qui a dicté toute la structure du site. Davy n'est ni un diagnostiqueur, celui qui fait les diagnostics obligatoires avant une vente, ni une entreprise de travaux, ni un expert judiciaire nommé par un tribunal. Il est indépendant, sans lien avec les assureurs, les artisans ou les banques, et il intervient souvent pour un particulier face à l'expert d'une compagnie d'assurance. Les gens confondent en permanence ces quatre métiers : la première mission du site n'était donc pas de vendre, mais d'expliquer.

Son activité se divise en deux. La pathologie du bâti d'abord : quand une maison se fissure, prend l'humidité ou qu'une façade se dégrade, il constate, explique l'origine du désordre et détermine les responsabilités. La valeur vénale ensuite : il estime ce que vaut un bien pour une succession, un divorce, une donation ou un contentieux. Ses clients sont des particuliers et des copropriétés, mais aussi des notaires et des avocats.

Sur la Côte d'Azur la demande ne manque pas : bâti ancien, sols argileux qui font travailler les fondations, et une région durement touchée par les inondations d'octobre 2015. Il intervient sur treize communes des Alpes-Maritimes, de Cannes à Monaco. Son problème n'était donc pas le marché, c'était la visibilité. Avant ce projet, le seul endroit où on pouvait le trouver en ligne était une fiche sur le site du réseau Vauban : quelqu'un qui tape « expert fissures Cannes » sur Google ne tombait pas sur lui.

Webcam Immobilier est une structure d'une seule personne : je travaillais directement avec le dirigeant, sans intermédiaire. Pas de graphiste, pas d'agence, pas de prestataire à côté. J'ai donc tout pris en charge.

Concrètement, sur ces sept semaines : transformer les réponses d'un questionnaire client en une structure de site ; créer son identité visuelle complète, logo, palette, déclinaisons et favicon ; produire la quarantaine d'images du site ; maquetter puis coder les pages en commençant systématiquement par le mobile ; brancher un système de gestion de contenu pour qu'il modifie ses textes et ses photos sans moi ; développer un formulaire de contact avec envoi de photos, parce que ses clients lui envoient des clichés de fissures ; travailler le référencement local, puisque toute son activité vient de recherches géolocalisées ; sécuriser l'ensemble, du formulaire jusqu'à la base de données ; mettre le site en ligne, configurer les noms de domaine et l'envoi des e-mails ; rédiger les mentions légales et la politique de confidentialité.

Côté technique, le site est développé en Next.js avec TypeScript et Tailwind CSS. Le contenu que Davy modifie lui-même est géré dans Sanity, un CMS headless. Les demandes du formulaire et les fichiers joints sont stockés dans Supabase — une base PostgreSQL et un espace de stockage — et les e-mails partent par Resend. La validation des données repose sur Zod, partagé entre le navigateur et le serveur pour que la même règle s'applique des deux côtés. L'hébergement est sur Vercel, les noms de domaine chez OVH.

Côté méthode, tout le projet est versionné sous Git : chaque évolution passe par un commit qui décrit ce qui change et pourquoi, ce qui m'a permis plusieurs fois de retrouver quand une régression était apparue. J'ai découpé le travail en cinq phases livrées l'une après l'autre — formulaire fonctionnel, mise en place du CMS, reprise des contenus du réseau Vauban, référencement et déploiement, puis nom de domaine et envoi d'e-mails. L'idée était que Davy ait quelque chose de testable à la fin de chaque phase, plutôt qu'un site complet à la toute fin.

Le site est en ligne depuis le 30 juillet 2026. Il compte environ 74 pages, dont 16 sous-pages d'expertise et 13 pages de ville.

J'ai commencé par les couleurs. Je lui ai proposé deux directions, une froide et une chaude, et il a choisi la chaude : un bordeaux profond comme couleur principale, un anthracite, un blanc cassé légèrement réchauffé pour les fonds et un noir chaud pour le texte. Quatre couleurs, pas plus. L'idée était de rester sobre et technique, parce qu'un expert qui arbitre un litige ne peut pas avoir l'air d'une agence commerciale.

Pour le logo, j'avais une contrainte intéressante. Davy appartient au réseau Les Experts Vauban, et être visuellement reconnaissable comme membre du réseau est un signal de crédibilité, pas un risque. Il fallait donc un air de famille avec leur identité, sans copier leur emblème. J'ai construit un monogramme BE en serif, avec la signature « observer, comprendre, conclure », décliné en version longue et courte, sur fond clair et sur fond sombre.

Le détail dont je suis le plus content, c'est le favicon. J'ai généré quatre variantes et je les ai comparées aux tailles réelles, 16, 32 et 48 pixels, sur un onglet clair puis sur un onglet sombre. Une seule restait lisible dans les deux cas : le monogramme en blanc plein sur un carré bordeaux. J'ai trouvé un piège au passage — la version blanche du logo garde le B en bordeaux, parce qu'elle est faite pour les fonds sombres ; posée sur un carré bordeaux, ce B disparaissait complètement. J'ai donc écrit un script qui dérive une version entièrement monochrome à partir du fichier source, ce qui permet de tout régénérer si le logo change un jour.

Enfin, j'ai produit les 39 images du site — les visuels des pages ville, des sous-pages d'expertise, des cartes d'activité — et j'ai écrit un script qui les convertit, les compresse et les envoie directement au bon endroit dans le back-office.

Les maquettes étaient en desktop et en basse fidélité, et il a fallu les réinterpréter. Parce que la règle que je me suis fixée dès le début, c'est le mobile d'abord : je conçois pour un téléphone, puis j'enrichis vers le grand écran. Sur ce projet ce n'était pas une préférence esthétique. Quand quelqu'un a une fissure et cherche un expert, il le fait depuis son téléphone, pas depuis un ordinateur de bureau.

Le parti pris s'est vérifié, mais pas tout de suite. À un moment j'ai fait auditer mes pages et j'ai découvert que sur un écran de 375 pixels, certains textes tombaient à 9,6 pixels — en dessous du seuil de lisibilité — et que des blocs recouvraient le titre principal. J'ai tout refait : une présentation verticale simple sur mobile, et la composition en blocs flottants réservée au desktop, avec un seul et même titre partagé entre les deux versions.

Pour la page d'accueil je voulais quelque chose qui raconte le métier tout de suite. J'ai fait une maison qui se fissure et s'effondre au fur et à mesure qu'on descend la page. Plutôt que de lire une vidéo, j'ai découpé la séquence en soixante images que je dessine dans un canvas selon la position de scroll. Puis je me suis rendu compte que sur téléphone on n'en voyait que 26 %, parce que la séquence était en format paysage. J'ai refait une version verticale, et j'ai fait en sorte que chaque appareil ne télécharge que celle dont il a besoin.

Côté base de données, j'ai activé la sécurité au niveau des lignes plutôt que de me reposer uniquement sur mon code. Le compte utilisé par le site ne peut faire qu'une seule chose : insérer. Il ne peut ni lire, ni modifier, ni supprimer. Même si quelqu'un récupérait la clé publique du site, il ne pourrait pas ressortir les demandes déjà enregistrées. J'ai aussi recopié les règles de validation directement en base, sous forme de contraintes, pour qu'un envoi mal formé soit rejeté même s'il n'est jamais passé par le site.

Côté formulaire, toute la validation est rejouée côté serveur, avec des listes de caractères autorisés champ par champ : pas de chiffre dans un prénom, pas de caractère de contrôle dans un message. J'ai ajouté un champ piège invisible pour les robots et un piège temporel qui rejette les envois trop rapides pour être humains.

Pour les fichiers, je ne fais pas confiance à l'extension annoncée. Je lis les premiers octets pour vérifier le vrai type du fichier, et je force l'extension réellement détectée au moment de le renommer. Je l'ai testé sur des cas tordus, dont un caractère Unicode qui inverse le sens de lecture et sert justement à maquiller une extension.

Contre les abus, j'ai mis en place une limitation du nombre d'envois, avec les seuils écrits côté base pour qu'ils ne soient pas modifiables depuis l'application. Les adresses IP ne sont jamais stockées en clair : je n'en garde qu'une empreinte, ce qui permet de compter les envois sans conserver de donnée personnelle.

Le reste, c'est du travail de fond : en-têtes de sécurité, politique de contenu, contrôle de l'origine des requêtes, protection contre le détournement d'un proxy d'images, signature cryptographique sur le point d'entrée automatisé, secrets jamais versionnés. Avec un principe appliqué partout : chaque compte reçoit le minimum de droits pour faire son travail, et rien de plus.

À la fin j'ai fait un audit complet, avec un script qui interroge directement la base pour vérifier les droits réels plutôt que ceux que je croyais avoir posés. Il m'a fait trouver deux écarts que je n'avais pas vus, dont un espace de stockage qui acceptait n'importe quel type de fichier en tapant son interface directement, ce qui contournait ma vérification.

J'ai donc branché le site sur un système de gestion de contenu que je n'avais jamais utilisé. Ça a été de loin la partie la plus longue et la plus ingrate du stage. Il a fallu modéliser chaque type de contenu, traduire l'interface en français, organiser les menus pour qu'ils soient compréhensibles par quelqu'un qui n'est pas développeur, et brancher chaque champ sur la bonne partie de chaque page.

Le vrai travail, c'était de penser à sa place. Un champ qui s'appelle « heroTagline » ne veut rien dire pour lui. Un champ « Ordre d'affichage » avec une explication en dessous, si. J'ai aussi ajouté un bouton dans son interface qui va chercher automatiquement les nouveaux articles publiés par le réseau Vauban et lui prépare des brouillons qu'il n'a plus qu'à relire et publier.

Aujourd'hui il crée une page de ville, la renomme, la supprime, réordonne son menu et publie un article sans que je touche à quoi que ce soit. C'est le résultat dont je suis le plus fier, et c'est aussi celui qui m'a donné le plus de mal.

J'ai donc traité le référencement comme une partie du produit, pas comme une option de fin de projet. Concrètement : une page dédiée par sujet d'expertise et par commune, un plan du site avec la vraie date de dernière modification de chaque page, des données structurées pour que Google comprenne le métier, les questions fréquentes et le fil de navigation, et des titres et descriptions que Davy peut régler lui-même page par page.

J'ai aussi posé un garde-fou dont je suis assez content. Tant que le site tournait sur une adresse provisoire, il était impossible qu'il se fasse indexer par erreur : une seule variable pilote tout, et si elle ne vaut pas exactement l'adresse définitive, le site se déclare non indexable. Je l'ai d'ailleurs corrigé une deuxième fois après coup, parce que dans sa première version, oublier la variable suffisait à déclarer le site indexable. Un garde-fou doit échouer du côté fermé, pas du côté ouvert.

Un mois après la mise en ligne, le site apparaît 767 fois dans les résultats de recherche et remonte peu à peu. Il est encore loin dans le classement, ce qui est normal pour un site aussi jeune sur un secteur concurrentiel. Mais le vrai indicateur est ailleurs : cinq personnes ont contacté Davy via le formulaire depuis le lancement. Avant le site, elles n'auraient eu aucun moyen de le trouver.

Mon maître de stage était Davy Bouhnik lui-même, le gérant de l'agence. Je travaillais principalement dans les locaux de Webcam Immobilier à Cannes, et le reste du temps depuis chez moi. Dans une structure de cette taille il n'y a aucune couche intermédiaire : pas de chef de projet, pas de service technique, pas de prestataire. Je rendais des comptes directement au dirigeant, qui était en même temps le client final — ce qui rendait chaque validation immédiate, mais aussi sans appel.

Nos échanges passaient par quatre canaux, et chacun avait son usage. Un questionnaire écrit au démarrage, qu'il a rempli et qui a servi de cahier des charges pendant tout le projet : j'y suis revenu à chaque doute sur le périmètre. Le face-à-face quand j'étais à l'agence, pour tout ce qui se décide mieux en montrant l'écran. Le téléphone le reste du temps, tous les jours et souvent plusieurs fois par jour — c'est d'ailleurs par téléphone qu'est arrivée une demande qui ne figurait nulle part dans le questionnaire, la reprise des articles du réseau Vauban. Et les captures d'écran qu'il m'envoyait quand quelque chose s'affichait mal chez lui, qui se sont révélées le moyen le plus efficace de me signaler un défaut que je ne voyais pas sur ma machine.

Ça change complètement la façon de travailler. J'avais une vraie autonomie sur la technique — le choix des outils, l'architecture, la sécurité, c'était moi — mais aucune décision visible ne partait sans validation. Et j'ai appris à traiter ses demandes autrement qu'en oui ou non. Quand il avait une idée, je cherchais d'abord à la réaliser telle quelle ; quand ce n'était pas faisable, je ne répondais pas « impossible », je revenais avec une proposition qui gardait son intention en la rendant réalisable.

Cette proximité a une contrepartie : chaque retour arrive immédiatement. Le premier jet de la page d'expertise ne respectait pas la maquette, il me l'a dit dans l'heure. Le fond de la page d'accueil était flou, il m'a envoyé une capture. Le rendu était bon sur ordinateur mais coupé en bas sur son iPhone, il l'a vu avant moi. Ces retours-là ne font pas plaisir sur le moment, mais ce sont eux qui ont fait la qualité finale.

J'ai aussi appris à dire non quand il fallait. Quand la page a eu besoin de ses mentions légales, il me manquait son numéro SIRET, son statut juridique et son assurance : j'ai laissé la page de côté et signalé le blocage, plutôt que de mettre un numéro plausible. Quand le numéro est arrivé, il faisait quinze chiffres au lieu de quatorze — je l'ai fait confirmer avant de l'intégrer. Et quand la section des avis clients est restée vide faute de vrais avis, je n'en ai pas inventé pour remplir la page.

La curiosité. Davy voulait afficher sur son site les articles publiés par son réseau professionnel. J'ai d'abord cherché un flux standard à lire, du type RSS : il n'y en avait pas. J'ai donc examiné comment leur site était construit, identifié le logiciel qui l'anime, et découvert que chaque article portait un identifiant interne stable. Je m'en suis servi comme clé pour ne jamais importer deux fois le même contenu. Mon premier script se trompait quand même : il réimportait tout à chaque lancement. En creusant, j'ai compris que ma requête de vérification interrogeait la base dans un mode qui ne voyait pas les brouillons — elle ne trouvait donc jamais ce que j'avais déjà importé. Une ligne à changer, deux heures pour la trouver, et un réflexe acquis : quand un contrôle ne détecte jamais rien, vérifier d'abord qu'il regarde au bon endroit.

La créativité. Ce même import posait un problème que je n'avais pas anticipé. Aller chercher les articles et leurs images sur un site tiers doit rester côté serveur ; mais les enregistrer dans le CMS demande un droit d'écriture, que je ne voulais surtout pas exposer dans le navigateur. Les deux besoins se contredisaient. Je les ai séparés : le serveur se contente de lire et de préparer les contenus, sans jamais rien écrire, et c'est l'interface du CMS qui les enregistre en utilisant la session de Davy, déjà connecté. Résultat, il lui suffit de cliquer sur un bouton pour récupérer les nouveaux articles, et aucun secret d'écriture ne quitte le serveur.

L'autonomie. La décision d'architecture dont je suis le plus sûr, je l'ai prise seul et à rebours de ce qu'on voit le plus souvent. La façon habituelle d'interroger une base depuis ce type de projet passe par un outil qui traduit le code en requêtes. Mais cet outil se connecte avec un compte privilégié qui contourne les règles de sécurité posées dans la base elle-même : toute la protection reposerait alors sur mon seul code applicatif. J'ai préféré écrire les requêtes à la main et laisser la base appliquer ses propres règles, quoi qu'il arrive côté application. C'est un peu plus long à écrire, et c'est ce qui fait qu'aujourd'hui la clé publique du site ne permet de lire aucune demande client.