Bouhnik Expertises

Webcam Immobilier is a limited company founded in April 2003, based at 14 avenue des Broussailles in Cannes. Davy Bouhnik has run it since January 2005 and works there alone. It is a FNAIM member agency positioned entirely on sales: no rentals, no property management, no building management. All of its time goes into selling the properties entrusted to it and searching for buyers who mandate it. It covers Cannes, Le Cannet, Mougins, Mandelieu-la-Napoule and the Cannes hinterland, with around forty properties on its books.

The market it operates in is expensive and tight. In the summer of 2026 a square metre in Cannes sits at roughly €5,800 to €6,100 according to the major property portals' indices, with a clear gap between flats, around €5,800, and houses, around €6,900. Across the department, the Alpes-Maritimes notaries' chamber reports a 2.4 % year-on-year rise in the resale market: measured growth, after several years of far sharper swings. In a market like that, a one-person agency does not stand out through the volume it handles, but through what it can do that others cannot. That is precisely what Davy's second activity brings — and what the site had to make visible.

Alongside the agency, Davy runs a second activity as a sole trader: surveying. That is the one my internship focused on, and the two answer each other — the agency's registered activity explicitly mentions property valuation alongside sales. He is an expert in building pathology and in market valuation, a member of the Institut International des Experts within the Les Experts Vauban network, and a lecturer at Toulouse Capitole University. More than twenty-five years in real estate.

The surveying market is a peculiar one, and it dictated the entire structure of the site. Davy is not a diagnostician, the person who carries out the mandatory checks before a sale; nor a building contractor; nor a court-appointed expert. He is independent, with no ties to insurers, tradespeople or banks, and he often acts for a private individual facing an insurance company's own expert. People confuse these four jobs constantly, so the first task of the site was not to sell, but to explain.

His work splits in two. Building pathology first: when a house cracks, takes in damp or a façade deteriorates, he inspects, explains where the damage comes from and establishes liability. Market valuation second: he assesses what a property is worth for an inheritance, a divorce, a gift or a dispute. His clients are private individuals and homeowner associations, but also notaries and lawyers.

On the French Riviera there is no shortage of demand: an ageing building stock, clay soils that shift foundations, and a region badly hit by the floods of October 2015. He covers thirteen towns across the Alpes-Maritimes, from Cannes to Monaco. His problem was never the market, it was visibility. Before this project, the only place he could be found online was a profile page on the Vauban network's website: someone searching for a crack surveyor in Cannes would never have found him.

Webcam Immobilier is a one-person business: I worked directly with the owner, with no one in between. No designer, no agency, no other contractor. So I took all of it on.

Over those seven weeks: turning the answers to a client questionnaire into a site structure; creating his full visual identity — logo, palette, variants and favicon; producing the site's forty or so images; wireframing then coding the pages, always starting with mobile; wiring up a content management system so he could edit his own text and photos; building a contact form with photo upload, because his clients send him pictures of cracks; working on local SEO, since his entire business comes from location-based searches; securing everything from the form down to the database; deploying the site, configuring the domain names and the outgoing email; and writing the legal notice and privacy policy.

On the technical side, the site is built with Next.js, TypeScript and Tailwind CSS. The content Davy edits himself is managed in Sanity, a headless CMS. Form enquiries and uploaded files are stored in Supabase — a PostgreSQL database plus a storage bucket — and emails go out through Resend. Data validation runs on Zod, shared between browser and server so the same rule applies on both sides. Hosting is on Vercel, the domain names are with OVH.

On method, the whole project is versioned with Git: every change goes through a commit describing what changes and why, which several times let me pinpoint when a regression had appeared. I split the work into five phases delivered one after another — working contact form, CMS setup, importing the Vauban network's content, SEO and deployment, then domain name and outgoing email. The idea was for Davy to have something testable at the end of each phase, rather than a finished site only at the very end.

The site has been live since 30 July 2026. It has around 74 pages, including 16 expertise sub-pages and 13 town pages.

I started with colour. I offered two directions, one cool and one warm, and he picked the warm one: a deep burgundy as the primary colour, a charcoal, a slightly warmed off-white for backgrounds and a warm black for text. Four colours, no more. The idea was to stay sober and technical, because an expert who settles disputes cannot look like a sales operation.

The logo came with an interesting constraint. Davy belongs to the Les Experts Vauban network, and being visually recognisable as a member is a credibility signal rather than a risk. So it needed a family resemblance to their identity without copying their emblem. I built a serif BE monogram with the line "observe, understand, conclude", in long and short versions, for light and dark backgrounds.

The detail I am happiest with is the favicon. I generated four variants and compared them at real sizes — 16, 32 and 48 pixels — on a light tab and then a dark one. Only one stayed legible in both cases: the monogram in solid white on a burgundy square. I found a trap along the way: the white version of the logo keeps its B in burgundy because it is made for dark backgrounds, so on a burgundy square that B vanished entirely. I therefore wrote a script that derives a fully monochrome version from the source file, which means everything can be regenerated if the logo ever changes.

Finally I produced the site's 39 images — the visuals for the town pages, the expertise sub-pages, the activity cards — and wrote a script that converts them, compresses them and pushes them straight to the right field in the back office.

The wireframes were desktop and low fidelity, so they had to be reinterpreted. Because the rule I set myself from the start was mobile first: design for a phone, then enrich towards the large screen. On this project that was not an aesthetic preference. When someone has a crack in their wall and looks for a surveyor, they do it from their phone, not from a desktop computer.

The choice proved right, but not straight away. At one point I had my pages audited and discovered that on a 375-pixel screen some text dropped to 9.6 pixels — below the legibility floor — and that blocks were covering the main heading. I redid all of it: a simple vertical layout on mobile, with the floating-block composition reserved for desktop, and a single shared heading across both versions.

For the home page I wanted something that tells you the job immediately. I made a house that cracks and collapses as you scroll down. Rather than playing a video, I cut the sequence into sixty images that I draw into a canvas according to scroll position. Then I realised that on a phone only 26 % of it was visible, because the sequence was landscape. I made a portrait version, and arranged things so each device only downloads the one it needs.

On the database side, I enabled row-level security rather than relying on my code alone. The account the site uses can do exactly one thing: insert. It cannot read, modify or delete. Even if someone obtained the site's public key, they could not pull out the enquiries already stored. I also copied the validation rules straight into the database as constraints, so a malformed submission is rejected even if it never went through the site.

On the form side, all validation is replayed server-side, with allowed-character lists field by field: no digits in a first name, no control characters in a message. I added an invisible trap field for bots and a timing trap that rejects submissions too fast to be human.

For uploaded files I do not trust the stated extension. I read the first bytes to check the file's real type, and force the actually detected extension when renaming it. I tested it on awkward cases, including a Unicode character that reverses reading direction and exists precisely to disguise an extension.

Against abuse, I put a submission rate limit in place, with the thresholds written on the database side so they cannot be changed from the application. IP addresses are never stored in the clear: I keep only a fingerprint, which allows counting submissions without retaining personal data.

The rest is groundwork: security headers, a content policy, request-origin checks, protection against hijacking of an image proxy, a cryptographic signature on the automated entry point, secrets never committed. With one principle applied throughout: every account gets the minimum rights needed to do its job, and nothing more.

At the end I ran a full audit, with a script that queries the database directly to check the rights that actually exist rather than the ones I believed I had set. It found two gaps I had missed, including a storage bucket that accepted any file type when its interface was called directly, bypassing my check.

So I wired the site to a content management system I had never used before. It was by far the longest and most thankless part of the internship. Every content type had to be modelled, the interface translated into French, the menus organised so they would make sense to someone who is not a developer, and every field connected to the right part of every page.

The real work was thinking on his behalf. A field called "heroTagline" means nothing to him. A field called "Display order" with an explanation underneath does. I also added a button in his interface that automatically fetches new articles published by the Vauban network and prepares drafts for him to review and publish.

Today he creates a town page, renames it, deletes it, reorders his menu and publishes an article without me touching anything. It is the result I am proudest of, and also the one that gave me the most trouble.

So I treated SEO as part of the product rather than an end-of-project extra. In practice: a dedicated page per expertise topic and per town, a sitemap carrying each page's real last-modified date, structured data so Google understands the trade, the FAQs and the navigation path, and titles and descriptions Davy can set himself page by page.

I also put in a safeguard I am fairly pleased with. While the site ran on a temporary address, it was impossible for it to be indexed by mistake: a single variable drives everything, and unless it matches the final address exactly, the site declares itself non-indexable. I actually fixed it a second time afterwards, because in its first version simply forgetting the variable was enough to declare the site indexable. A safeguard has to fail closed, not open.

A month after launch the site appears 767 times in search results and is slowly climbing. It still ranks low, which is normal for a site this young in a competitive field. But the real indicator is elsewhere: five people have contacted Davy through the form since launch. Before the site, they would have had no way of finding him.

My placement supervisor was Davy Bouhnik himself, the agency's director. I worked mainly from Webcam Immobilier's offices in Cannes, and the rest of the time from home. In a company this size there is no layer in between: no project manager, no technical department, no other contractor. I reported directly to the owner, who was also the end client — which made every approval immediate, but also final.

We used four channels, each with its own purpose. A written questionnaire at the start, which he filled in and which served as the brief throughout the project: I went back to it whenever the scope was unclear. Face to face when I was at the agency, for anything better settled by showing the screen. The phone the rest of the time, every day and often several times a day — it was over the phone that a request arrived which appeared nowhere in the questionnaire, importing the Vauban network's articles. And the screenshots he sent whenever something displayed badly on his end, which turned out to be the most effective way of flagging a fault I could not see on my own machine.

That changes the way you work entirely. I had real autonomy on the technical side — the tools, the architecture, the security were mine to decide — but nothing visible shipped without approval. And I learned to handle his requests as something other than a yes or a no. When he had an idea, I first tried to build it as stated; when that was not feasible, I did not answer "impossible", I came back with a proposal that kept his intent while making it buildable.

That closeness has a flip side: every piece of feedback arrives immediately. The first draft of the expertise page did not match the wireframe, and he told me within the hour. The home page background was blurry, and he sent me a screenshot. The layout looked right on a computer but was cut off at the bottom on his iPhone, and he spotted it before I did. That kind of feedback is not pleasant at the time, but it is what made the final quality.

I also learned to say no when it was warranted. When the legal notice was due, I was missing his company number, his legal status and his insurance details: I set the page aside and flagged the blocker rather than putting in a plausible-looking number. When the number arrived it had fifteen digits instead of fourteen — I had it confirmed before using it. And when the testimonials section stayed empty for lack of real reviews, I did not invent any to fill the page.

Curiosity. Davy wanted his site to display the articles published by his professional network. I first looked for a standard feed to read, something like RSS: there wasn't one. So I examined how their site was built, identified the software running it, and discovered that every article carried a stable internal identifier. I used it as the key so the same content would never be imported twice. My first script still got it wrong: it re-imported everything on each run. Digging in, I realised my check query was reading the database in a mode that could not see drafts — so it never found what I had already imported. One line to change, two hours to find it, and a reflex acquired: when a check never detects anything, first make sure it is looking in the right place.

Creativity. That same import raised a problem I had not anticipated. Fetching the articles and their images from a third-party site has to stay server-side; but saving them into the CMS requires write access, which I absolutely did not want exposed in the browser. The two needs contradicted each other. I separated them: the server only reads and prepares the content, never writing anything, and it is the CMS interface that saves it using Davy's own session, since he is already signed in. As a result, one click fetches the new articles and no write secret ever leaves the server.

Autonomy. The architectural decision I am most confident about, I made alone and against what you most often see. The usual way to query a database from this kind of project goes through a tool that translates code into queries. But that tool connects with a privileged account which bypasses the security rules set inside the database itself: all the protection would then rest on my application code alone. I chose to write the queries by hand and let the database enforce its own rules, whatever happens on the application side. It takes a little longer to write, and it is the reason why today the site's public key cannot read a single client enquiry.