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 just watching a demo that talks well without knowing if it actually helps.
And a useful result isn't necessarily a chat bubble accessible to everyone. Finding internal information faster can be much more valuable than a chatbot greeting visitors with a friendly phrase.
An invented schedule or a misinterpreted refund policy can be enough to create a real problem for the client. Providing the right documents helps, but doesn't guarantee every answer will be correct. The NIST Risk Management Framework specifically addresses this production of false information with confidence.
I prefer an assistant to admit it's missing 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 proofreading can then more easily find what they need to check.
The same difference applies between suggesting a booking change 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.
So we can move 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 trust it with 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. The CNIL's Q&A on generative AI provides guidance on these precautions. Plugging in 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. If a simpler automation is enough, we have the right to choose that too.
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 it, corrects it 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 just watching a demo that talks well without knowing if it actually helps.
And a useful result isn't necessarily a chat bubble accessible to everyone. Finding internal information faster can be much more valuable 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 policy can be enough to create a real problem for the client. Providing the right documents helps, but doesn't guarantee every answer will be correct. The NIST Risk Management Framework specifically addresses this production of false information with confidence.
I prefer an assistant to admit it's missing 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 proofreading 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 a different kind of intervention.The same difference applies between suggesting a booking change 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.
So we can move 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 trust it with in real cases before expanding its role.
A client file doesn't become public just because the question is simple
To answer "what are your opening 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. The CNIL's Q&A on generative AI provides guidance on these precautions. Plugging in all messages just to see what happens would be a rather uncomfortable start.
Help is judged after proofreading
If the draft arrives in seconds but then takes ten minutes to correct, we haven't necessarily simplified the work. So we 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. If a simpler automation is enough, we have the right to choose that too.
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.
