AI in web development
Before adding AI to your site, choose a useful task. Define sources, permissions, and controls to evaluate a prototype and ensure real business value.
Sur cette page5 sections
You receive a question that looks a lot like one from yesterday. The answer exists somewhere, but you have to find the document, check the client's case, and rewrite a clean message. It's not spectacular work. However, by doing it repeatedly, you eventually think that a little help would be welcome.
This is a starting point that speaks to me much more than "we should put AI on the site." We already know what takes time and what useful help would look like. The choice of tool can come later.
The value of the first trial is also this: if the result is poor, someone can explain why. A forgotten condition, an outdated document, a response that mixes two offers. We have something to improve, instead of standing before a demonstration that speaks well without knowing if it helps.
And a useful result isn't necessarily a chat bubble accessible to everyone. Finding information faster internally can have much more value than a chatbot greeting visitors with a friendly phrase.
An invented schedule or a misinterpreted refund condition can be enough to create a real problem for the client. Providing the right documents helps, but doesn't guarantee every response will be correct. Le NIST Risk Management Framework specifically addresses this production of false information with confidence.
I prefer an assistant to admit it lacks information and hand over the task, rather than finishing its sentence at all costs. In our example, we can ask it to show the sources used in the draft: the person reviewing can then more easily find what they need to check.
The same difference applies between suggesting a booking modification and actually making it. If we give the assistant the ability to act, we specify its access, permitted actions, and required confirmations. The quality of its conversation doesn't automatically give it the right to touch everything.
We can therefore move forward in stages, first entrusting it with preparation and keeping validation in the right place. This doesn't make the project less ambitious. It's about learning what we can entrust to it in real cases before expanding its role.
This is an issue to be resolved in how we link tools and data, not just with a polite instruction in the conversation. We separate public information, internal access, and what each user is authorised to view.
We also look at what the provider does with the transmitted data and how long it is kept. Les CNIL's Q&A on generative AI provides guidance on these precautions. Connecting all messages just to see what happens would be a rather uncomfortable start.
To work on your project, show me a repetitive task that annoys you and how you do it today. We can try a first version on representative cases and decide what to keep. Si une simpler automation is enough, we also have the right to choose it.
What interests me is the moment someone can say "this really helps me," not when the tool manages to talk for five minutes without catching its breath.
This is a starting point that speaks to me much more than "we should put AI on the site." We already know what takes time and what useful help would look like. The choice of tool can come later.
Let's start with a response you could handle yourself
Imagine an assistant that prepares a draft based on your documents. Your team reviews, corrects if necessary, and sends the message. We can test it on requests they already know, then see if the draft actually saves them time.The value of the first trial is also this: if the result is poor, someone can explain why. A forgotten condition, an outdated document, a response that mixes two offers. We have something to improve, instead of standing before a demonstration that speaks well without knowing if it helps.
And a useful result isn't necessarily a chat bubble accessible to everyone. Finding information faster internally can have much more value than a chatbot greeting visitors with a friendly phrase.
The problem of the colleague who answers with far too much confidence
You might know this situation: someone answers without hesitation, everyone believes them, and then you discover they misunderstood the question. With generative AI, a fluid response can give exactly that impression of mastery, even when it contains an error.An invented schedule or a misinterpreted refund condition can be enough to create a real problem for the client. Providing the right documents helps, but doesn't guarantee every response will be correct. Le NIST Risk Management Framework specifically addresses this production of false information with confidence.
I prefer an assistant to admit it lacks information and hand over the task, rather than finishing its sentence at all costs. In our example, we can ask it to show the sources used in the draft: the person reviewing can then more easily find what they need to check.
Preparing a message and clicking send
These are two different responsibilities. A slightly clumsy draft can be corrected before it goes out; a message sent to the wrong client already requires another intervention.The same difference applies between suggesting a booking modification and actually making it. If we give the assistant the ability to act, we specify its access, permitted actions, and required confirmations. The quality of its conversation doesn't automatically give it the right to touch everything.
We can therefore move forward in stages, first entrusting it with preparation and keeping validation in the right place. This doesn't make the project less ambitious. It's about learning what we can entrust to it in real cases before expanding its role.
The client file doesn't become public just because the question is simple
To answer "what are your hours?", the assistant doesn't need to read the private exchanges of all your clients. To find information in a file, it must not show the neighbour's file either.This is an issue to be resolved in how we link tools and data, not just with a polite instruction in the conversation. We separate public information, internal access, and what each user is authorised to view.
We also look at what the provider does with the transmitted data and how long it is kept. Les CNIL's Q&A on generative AI provides guidance on these precautions. Connecting all messages just to see what happens would be a rather uncomfortable start.
Help is judged after the review
If the draft arrives in seconds but then takes ten minutes to correct, we haven't necessarily simplified the work. We therefore count usable responses, errors, and the time actually spent, including the costs of the service and the tools called.To work on your project, show me a repetitive task that annoys you and how you do it today. We can try a first version on representative cases and decide what to keep. Si une simpler automation is enough, we also have the right to choose it.
What interests me is the moment someone can say "this really helps me," not when the tool manages to talk for five minutes without catching its breath.
