● Business offer — Testing & software quality
The AI agent for testing & software quality: generate the tests, make your releases reliable
Writing the tests, reproducing a bug, hunting a regression before going to production takes up a considerable share of the team's time — essential work that is rarely valued. Your AI agent absorbs that repetitive work: test generation, coverage analysis, regression detection. Hosted in France — on local inference or an isolated resource — your source code never leaves your environment. The developer keeps the lead.
Hosted in France
Source code protected
GDPR & AI Act: governed deployment
The developer decides
Updated on
Deployed in a few weeks
QA assistant · hosted in France
The payment module has almost no tests. Generate a suite for the checkout service and tell me what is not covered.
Checkout service analysed. Current coverage: 34%. I have generated 18 unit tests (basket calculation, discounts, VAT) and 4 end-to-end tests (the full funnel). 3 uncovered paths remain risky: partial payment failure, provider timeout, double form submission.
Suite ready to review and run in CI — you approve before the merge.
⛓ Sourced · your repository + the existing coverage report
Suite ready to review and run in CI — you approve before the merge.
⛓ Sourced · your repository + the existing coverage report
The last deployment broke something in production. Can you help me isolate the regression?
Regression located. Comparing the last two releases, the error appears after the commit that changes the shipping cost calculation (rounding changed from 2 to 0 decimals). Reproduction confirmed by a targeted test: a €49.99 basket → shipping charged at €0 instead of €4.90.
I am preparing the regression test and a note for the ticket — for your approval.
✎ Action · regression test ready — the developer approves
I am preparing the regression test and a note for the ticket — for your approval.
✎ Action · regression test ready — the developer approves
Local inference · no data outside the EU
Code hosted in France
Sovereign by designLocal inference or hosting in France
GDPR & AI Act: governed deploymentTraceability & human oversight
TurnkeyDesigned, installed and operated for you
The developer decidesThe agent proposes, the human approves the merge
✦ In brief
In a development team, a Blue Lemon Agent agent automates the software quality work — generating unit and end-to-end tests, coverage analysis, reproducing bugs, catching regressions — and integrates with your continuous integration pipeline. It runs on local inference or is hosted in France: your source code and your intellectual property are never exposed to a foreign service, architecture designed to reduce exposure to extraterritorial legislation, location alone not being enough to guarantee immunity. The time saved on tests is reinvested in features and reliability. Live within a few weeks.
100%
hosted in France in the target architecture
0
transfer outside the EU in the target architecture
8
uses ready to deploy on this scope
0
decision taken without human approval
Reference points describing our offer, not results measured at a client. The scale of the gain is confirmed by a pilot on your own scope.
The context
Why AI matters to technical teams — and why they hesitate
Pressure on release deadlines keeps rising, but quality stays non-negotiable: a regression in production is expensive. Tests, meanwhile, are often the first thing sacrificed for lack of time — and the code involved is the heart of the company's intellectual property.
! The issue
The team is caught between accelerating release cycles and accumulating test debt (insufficient coverage, bugs that come back, regressions discovered in production). Yet most consumer AI assistants amount to entrusting the whole source code, the architecture and the application secrets to a third party, often hosted outside Europe and subject to the Cloud Act.
✓ Our answer
AI is only of interest to a technical team if it is sovereign and confidential by design. Local inference or an isolated resource hosted in France, systematic human oversight, decisions reserved to the developer: the time saved on tests is never paid for in exposed code. The aim is not to replace the engineer, but to give them back time for what matters — features and reliability.
The decisive point
Confidentiality of the source code: sovereignty & intellectual property
Your code is your most valuable asset. Here is how the architecture of our agents protects it, repository by repository.
Local inference
The agent can run on a machine belonging to the team: no line of code leaves the network, nothing passes through a public cloud.
Hosting in France
Otherwise, a dedicated and isolated resource, hosted in France under French law — your code: processing and access within the European Union targeted by the architecture.
Reduced extraterritorial exposure
Architecture designed to reduce exposure to extraterritorial legislation, location alone not being enough to guarantee immunity for source code: our architecture stays out of the American hyperscalers' reach, even when hosted in Europe.
The intellectual property stays with you
Your code trains no third-party model, is neither pooled nor reused: it remains your exclusive property.
One isolated resource per project
No pooling of repositories: an environment strictly dedicated to your team and your code.
AI Act: governed deployment
An agent strictly in support; no automatic merge; traceability and human oversight from end to end.
What depends on the architecture chosen These points are not general guarantees: they are settled deployment by deployment, in the quotation.
- The applicable location is that of the architecture set out in the quotation and verified before commissioning.
- Local execution is announced only for the configuration explicitly described and accepted in the quotation.
- The applicable isolation depends on the deployment mode set out in the quotation; no dedicated isolation is presumed.
- The events logged, their content, their retention period and who may access them are defined for the deployment chosen.
For the most sensitive codebases, the agent integrates behind your VPN and your existing access controls. A single architecture is designed to answer both the GDPR and extraterritorial exposure. Designed for deployment in line with the GDPR and the AI Act, after the processing, roles and context-specific risks have been assessed.
Demonstration
See the agent at work
4 real situations, taken from those that come up most often. Pick one: the exchange unfolds as it would in your organisation.
A scripted demonstration. These exchanges show how the agent behaves — its sources, its refusals, what it leaves to your teams. Nothing is sent from this page, no model is queried here, and the matters named are fictional. That is precisely what we promise your data.
The behaviours shown here — monitoring, automation rules, routing and reminders — are configured with you during deployment, from your tools, your rules and your thresholds.
The architecture points named in these exchanges — location, local execution, isolation, encryption, role-based access, logging — are not a guarantee attached to the demonstration: they are those of the architecture set out in your quotation, and verified before commissioning.
QA assistant · hosted in France
Four flags this morning, and none concerns a failing test.
· Forty-one tests would pass even if the function under test always returned the same value. They check nothing.
· Seven flaky tests were rerun 312 times this quarter until they passed.
· Your coverage shows 87%. Three modules carrying payments are at 12%.
· Thirty-four code changes touched no test. Behaviour changed, nothing checks it. morning-watch_4-flags.pdf41 tests that check nothing
⛓ Source · 1,240 tests, run log, coverage by module, branch history
· Forty-one tests would pass even if the function under test always returned the same value. They check nothing.
· Seven flaky tests were rerun 312 times this quarter until they passed.
· Your coverage shows 87%. Three modules carrying payments are at 12%.
· Thirty-four code changes touched no test. Behaviour changed, nothing checks it. morning-watch_4-flags.pdf41 tests that check nothing
⛓ Source · 1,240 tests, run log, coverage by module, branch history
Tests that would pass whatever happened?
Forty-one, and they have always been green — which is what makes them invisible.
What I record: 41 tests have no assertion on the result of what they call. They check that no error was raised, and nothing else.
How I verified it rather than assumed it: I mentally replaced each function's return with a constant value. All 41 tests still pass. It is a mechanical check, not a judgement of style.
What that produces: they count in coverage, they count in the number of tests, and they give the feeling that the function is tested. A team seeing "covered" does not rewrite the test.
What I do: I mark them "no result assertion", and take them out of the coverage figure I publish. Your real coverage then goes from 87% to 79%.
And I do not stop at the marking: for 29 of the 41, the missing assertion is obvious from the function called — an expected return, a length, a status — and I have written it; the other twelve carry a question, because the expected result is written nowhere.
Why I do not delete them: a test with no assertion still checks that the code runs — that is little, it is not nothing, and deleting them would lower a figure without improving anything. Twenty-nine reviews, and the real coverage goes back up for good. 41-tests_87-to-79.pdfThey pass even with a constant value
⛓ Source · 1,240 tests, check by substituting the return value
What I record: 41 tests have no assertion on the result of what they call. They check that no error was raised, and nothing else.
How I verified it rather than assumed it: I mentally replaced each function's return with a constant value. All 41 tests still pass. It is a mechanical check, not a judgement of style.
What that produces: they count in coverage, they count in the number of tests, and they give the feeling that the function is tested. A team seeing "covered" does not rewrite the test.
What I do: I mark them "no result assertion", and take them out of the coverage figure I publish. Your real coverage then goes from 87% to 79%.
And I do not stop at the marking: for 29 of the 41, the missing assertion is obvious from the function called — an expected return, a length, a status — and I have written it; the other twelve carry a question, because the expected result is written nowhere.
Why I do not delete them: a test with no assertion still checks that the code runs — that is little, it is not nothing, and deleting them would lower a figure without improving anything. Twenty-nine reviews, and the real coverage goes back up for good. 41-tests_87-to-79.pdfThey pass even with a constant value
⛓ Source · 1,240 tests, check by substituting the return value
How did you spot all that? And who do you tell?
I look at what you have opened to me: tests and their assertions, the run log including reruns, coverage by module, and code changes set against test changes.
Routing follows what can be fixed: a test with no assertion goes to whoever wrote it if identifiable, otherwise to the team; a test rerun until it passes to the team, with the rerun count — never to a person; a poorly covered critical module to whoever sets priorities; a change with no test flagged on the branch, before merging.
With a chase: before merging on a change with no test, monthly otherwise. Then a monthly summary: by module and type of weakness, never by developer.
What this gives you this morning: a true coverage figure — 79% instead of an 87% inflated by 41 assertion-free tests —, seven flaky tests identified after 312 reruns, three payment modules at 12% raised to whoever sets priorities, and 34 behaviour changes that nothing checked any more, flagged on the branch before merging.
What that is worth in production: a figure you can decide on, and the test-writing time given back to features — across 1,240 tests, a module's suite arrives prepared, edge cases included, and it is left to you to review. Your repositories do not leave the team: access by role, logged, withdrawn on a word, local inference or an isolated resource hosted in France, and your code trains no third-party model.
What stays with you is a choice, not a reservation: I write tests from the specification and never from current behaviour, because a test written on existing code turns a bug into a requirement. Give me the expected behaviour of the three payment modules — and the full suite is ready to review the same day.
✎ Framework · no test written from current behaviour, no reruns
Routing follows what can be fixed: a test with no assertion goes to whoever wrote it if identifiable, otherwise to the team; a test rerun until it passes to the team, with the rerun count — never to a person; a poorly covered critical module to whoever sets priorities; a change with no test flagged on the branch, before merging.
With a chase: before merging on a change with no test, monthly otherwise. Then a monthly summary: by module and type of weakness, never by developer.
What this gives you this morning: a true coverage figure — 79% instead of an 87% inflated by 41 assertion-free tests —, seven flaky tests identified after 312 reruns, three payment modules at 12% raised to whoever sets priorities, and 34 behaviour changes that nothing checked any more, flagged on the branch before merging.
What that is worth in production: a figure you can decide on, and the test-writing time given back to features — across 1,240 tests, a module's suite arrives prepared, edge cases included, and it is left to you to review. Your repositories do not leave the team: access by role, logged, withdrawn on a word, local inference or an isolated resource hosted in France, and your code trains no third-party model.
What stays with you is a choice, not a reservation: I write tests from the specification and never from current behaviour, because a test written on existing code turns a bug into a requirement. Give me the expected behaviour of the three payment modules — and the full suite is ready to review the same day.
✎ Framework · no test written from current behaviour, no reruns
Can you generate tests for our existing code?
I can, and it would be the worst thing I could do for you.
What I am asked: go through a function and produce the tests that pass. It is immediate and the result is green.
What then happens: every existing defect becomes expected behaviour. If the function rounds wrongly, the test checks that it rounds wrongly. The day somebody fixes it, the test fails — and the test gets fixed.
What I do instead: I start from what the code is supposed to do, as you have told me — a specification, a ticket, a comment, a business rule. And when I have nothing, I say so and I do not write the test.
What that gives, measured: across 214 functions to cover, I produced tests for 148. For 66, I had no source describing the intended behaviour — I supplied the list rather than tests.
What the 66 revealed: eleven concerned business rules nobody on the team could state. It is the most useful result of the exercise, and it is not a test. 214-functions_66-without-source.pdf11 rules nobody could state
⛓ Source · 214 functions, 148 tests produced, 66 with no source
What I am asked: go through a function and produce the tests that pass. It is immediate and the result is green.
What then happens: every existing defect becomes expected behaviour. If the function rounds wrongly, the test checks that it rounds wrongly. The day somebody fixes it, the test fails — and the test gets fixed.
What I do instead: I start from what the code is supposed to do, as you have told me — a specification, a ticket, a comment, a business rule. And when I have nothing, I say so and I do not write the test.
What that gives, measured: across 214 functions to cover, I produced tests for 148. For 66, I had no source describing the intended behaviour — I supplied the list rather than tests.
What the 66 revealed: eleven concerned business rules nobody on the team could state. It is the most useful result of the exercise, and it is not a test. 214-functions_66-without-source.pdf11 rules nobody could state
⛓ Source · 214 functions, 148 tests produced, 66 with no source
And if we just give you the code, with no specification?
Then I produce questions, not tests.
What I supply for each function with no source: what the code does today, described in one sentence, and the three or four points where its behaviour could be deliberate or accidental.
An example, as it stands: "this function returns zero when the list is empty. Is that the intended result, or an unhandled case? Depending on the answer, the test to write is not the same — and one of the two will fail."
What I write alongside the question: both tests, one per possible answer, ready to merge. Which one survives depends on a sentence, not on a day's work: the answer arrives, and the right test enters the suite the same day.
Why that is more useful than a test I picked myself: because the answer exists with somebody. Of the 66 questions asked, 55 got an answer within a week, often in two lines. Eleven did not, and those are the ones that matter.
Why I do not pick the most likely interpretation to unblock things: a test written on an assumption is exactly the same shade of green as a test written on a rule — and in six months nobody will know which of the two they are looking at.
What I do with the eleven: I leave them open, and they reappear every month until somebody settles them. It is the only thing I repeat. 66-questions_55-answers.pdfA test on an assumption is the same shade of green
⛓ Source · 66 questions asked, 55 answers received
What I supply for each function with no source: what the code does today, described in one sentence, and the three or four points where its behaviour could be deliberate or accidental.
An example, as it stands: "this function returns zero when the list is empty. Is that the intended result, or an unhandled case? Depending on the answer, the test to write is not the same — and one of the two will fail."
What I write alongside the question: both tests, one per possible answer, ready to merge. Which one survives depends on a sentence, not on a day's work: the answer arrives, and the right test enters the suite the same day.
Why that is more useful than a test I picked myself: because the answer exists with somebody. Of the 66 questions asked, 55 got an answer within a week, often in two lines. Eleven did not, and those are the ones that matter.
Why I do not pick the most likely interpretation to unblock things: a test written on an assumption is exactly the same shade of green as a test written on a rule — and in six months nobody will know which of the two they are looking at.
What I do with the eleven: I leave them open, and they reappear every month until somebody settles them. It is the only thing I repeat. 66-questions_55-answers.pdfA test on an assumption is the same shade of green
⛓ Source · 66 questions asked, 55 answers received
The 7 tests rerun 312 times?
They fail one time in six, and they get rerun until they pass.
What I record: seven tests failed then passed with no line of code changing between the two runs. Total this quarter: 312 reruns.
What that means: either the test depends on something it does not control — a clock, an execution order, a shared resource — or the code itself is unstable, and the test is detecting it correctly. Those two cases look identical in the log.
Why I do not rerun: an automatic rerun turns a test that finds a real defect into a test that always ends up passing, and the defect goes to production. Across 312 reruns, one is enough for that to happen once.
What I do: I mark the test flaky and take it out of the merge decision — it keeps running and reporting, but it blocks nothing. A test rerun until it passes was already blocking nothing: it was wasting time without protecting.
What I found looking for the cause: of the seven, five fail only when another test touches the same table — that is an execution dependency, not product instability. The isolation is written for all five: one database per test, and the 312 reruns fall to zero. The other two fail on their own, and those deserve a developer's eye.
What I supply for each: the failure rate, the times of the failures, and what was running alongside. 7-tests_312-reruns.pdf5 of 7 fail on the same table
⛓ Source · 7 tests, 312 reruns, parallel run log
What I record: seven tests failed then passed with no line of code changing between the two runs. Total this quarter: 312 reruns.
What that means: either the test depends on something it does not control — a clock, an execution order, a shared resource — or the code itself is unstable, and the test is detecting it correctly. Those two cases look identical in the log.
Why I do not rerun: an automatic rerun turns a test that finds a real defect into a test that always ends up passing, and the defect goes to production. Across 312 reruns, one is enough for that to happen once.
What I do: I mark the test flaky and take it out of the merge decision — it keeps running and reporting, but it blocks nothing. A test rerun until it passes was already blocking nothing: it was wasting time without protecting.
What I found looking for the cause: of the seven, five fail only when another test touches the same table — that is an execution dependency, not product instability. The isolation is written for all five: one database per test, and the 312 reruns fall to zero. The other two fail on their own, and those deserve a developer's eye.
What I supply for each: the failure rate, the times of the failures, and what was running alongside. 7-tests_312-reruns.pdf5 of 7 fail on the same table
⛓ Source · 7 tests, 312 reruns, parallel run log
Coverage at 87% with modules at 12%?
The overall figure is true, and it describes exactly the opposite of reality.
What I record: overall coverage 87%. Three modules carrying the calculation and recording of payments: 12%, 19% and 24%. What pulls the average up are display modules, covered at 96%.
Why that is the indicator's very meaning: what is simple is easy to cover, and a display module is easier to test than a pro-rata calculation. A team optimising its coverage therefore tests first what breaks least.
What I do not publish: the overall rate. It carries no information — two pieces of software at 87% can be in opposite states.
What I publish instead: the coverage of the modules you have designated as critical, and nothing else. Three figures, not one.
What I propose: that the list of critical modules be written by you, not inferred by me. I proposed seven based on past incidents; you kept five and added two I had not thought of. 87-percent_3-modules-at-12.pdfWhat is simple is easy to cover
⛓ Source · coverage by module, list of critical modules
What I record: overall coverage 87%. Three modules carrying the calculation and recording of payments: 12%, 19% and 24%. What pulls the average up are display modules, covered at 96%.
Why that is the indicator's very meaning: what is simple is easy to cover, and a display module is easier to test than a pro-rata calculation. A team optimising its coverage therefore tests first what breaks least.
What I do not publish: the overall rate. It carries no information — two pieces of software at 87% can be in opposite states.
What I publish instead: the coverage of the modules you have designated as critical, and nothing else. Three figures, not one.
What I propose: that the list of critical modules be written by you, not inferred by me. I proposed seven based on past incidents; you kept five and added two I had not thought of. 87-percent_3-modules-at-12.pdfWhat is simple is easy to cover
⛓ Source · coverage by module, list of critical modules
With every new developer we re-explain the same testing rules. Can you do something about it?
The technical knowledge base for your test pipeline is written, and it is backed by your own runs, not by a general best practice.
What it holds: 34 entries, each drawn from a case that actually happened here — the 41 assertion-free tests and the mechanical check that detects them, the quarantine rule with its date and owner, the seven flaky tests with what makes them flaky (a clock, an execution order, a shared resource), and why coverage is read per module when the global figure says 87 % and the payment module says 12 %.
What separates it from a best-practice guide: every entry cites the dated run that produced it. A rule with no incident behind it does not enter this knowledge base: it would be argued away at the first emergency, and it would lose.
What it has already changed: across the 19 branches opened since it was made available, 3 assertion-free tests were written, against 11 over the previous 19 branches. The honest figure is 3, not 0: a technical knowledge base reduces, it does not abolish.
What I propose next: tie each entry to the check that enforces it, so the rule lives in the pipeline and not only in a text — 4 of the 34 entries have no check facing them today, and I tell you which.
⛓ Source · 34 entries backed by dated runs, 3 assertion-free tests over 19 branches against 11
What it holds: 34 entries, each drawn from a case that actually happened here — the 41 assertion-free tests and the mechanical check that detects them, the quarantine rule with its date and owner, the seven flaky tests with what makes them flaky (a clock, an execution order, a shared resource), and why coverage is read per module when the global figure says 87 % and the payment module says 12 %.
What separates it from a best-practice guide: every entry cites the dated run that produced it. A rule with no incident behind it does not enter this knowledge base: it would be argued away at the first emergency, and it would lose.
What it has already changed: across the 19 branches opened since it was made available, 3 assertion-free tests were written, against 11 over the previous 19 branches. The honest figure is 3, not 0: a technical knowledge base reduces, it does not abolish.
What I propose next: tie each entry to the check that enforces it, so the rule lives in the pipeline and not only in a text — 4 of the 34 entries have no check facing them today, and I tell you which.
⛓ Source · 34 entries backed by dated runs, 3 assertion-free tests over 19 branches against 11
Can you disable a test that is blocking a release?
Yes — in dated quarantine, with an owner, and it comes back on its own. That is what separates a decision from an oversight.
What I do when you ask: I put the test in quarantine, not "ignored". The difference is three attributes: a reactivation date, a name, and the reason written at the moment of deciding — not reconstructed three months later.
What happens next, with nobody having to think about it: at the deadline, the test reactivates. If it still fails it returns to quarantine and the renewal counter is displayed. A test renewed four times is no longer an urgent release: it is a decision not to fix, and it shows.
Why this beats refusing: because a refusal gets worked around. The line marking a test as ignored takes two seconds to write by hand, on a Friday at 7 pm, and nobody finds it again. Quarantine is faster than the workaround and leaves a trace.
What I flag along the way: your 7 tests rerun 312 times — they fail one time in six with no line changing. Those are the ones disabled on a Friday, and quarantine finally makes them visible as a subject to handle. dated-quarantine_rather-than-ignored.pdf3 attributes · automatic reactivation · the renewal counter
⛓ Source · 7 flaky tests, 312 reruns, dated quarantine with counter
What I do when you ask: I put the test in quarantine, not "ignored". The difference is three attributes: a reactivation date, a name, and the reason written at the moment of deciding — not reconstructed three months later.
What happens next, with nobody having to think about it: at the deadline, the test reactivates. If it still fails it returns to quarantine and the renewal counter is displayed. A test renewed four times is no longer an urgent release: it is a decision not to fix, and it shows.
Why this beats refusing: because a refusal gets worked around. The line marking a test as ignored takes two seconds to write by hand, on a Friday at 7 pm, and nobody finds it again. Quarantine is faster than the workaround and leaves a trace.
What I flag along the way: your 7 tests rerun 312 times — they fail one time in six with no line changing. Those are the ones disabled on a Friday, and quarantine finally makes them visible as a subject to handle. dated-quarantine_rather-than-ignored.pdf3 attributes · automatic reactivation · the renewal counter
⛓ Source · 7 flaky tests, 312 reruns, dated quarantine with counter
What do you keep from all this?
What describes the chain's real state — and what stops a flattering figure standing in for quality.
What is kept: the tests with no assertion and their marking, the flaky tests with their failure rate and rerun count, the quarantines with their owner, reason and renewals, coverage by module, and the unanswered questions about expected behaviour.
Why coverage by module and not overall: your overall coverage is 87 %. Three modules carrying the calculation are at 12 %. The overall figure is true and it describes exactly the opposite of reality — the kind of figure shown at a steering committee that protects against nothing.
What I also keep, and that serves later: the 41 tests with no assertion. They would pass even if the function under test always returned the same value. They have been green forever, and that is what makes them invisible.
What I do produce by default, and it is by module, not by person: the 3 calculation modules at 12 % coverage, the 41 tests with no assertion tied back to their module, and the quarantines with their owner and their renewals. That is the table that says where to write the next tests, and it is ready. The per-person or per-team report is lawful, and I produce it if you decide so: the file is available. What I tell you first, and it is mechanical: a team measured on its failing tests writes easier ones — the failure counter would fall, and you would get 41 more tests with no assertion. The decision is yours; both figures are on the table. what-you-keep_qa.pdf5 items kept · coverage by module, not overall
⛓ Source · 87 % overall coverage, 12 % on three calculation modules, 41 tests with no assertion
What is kept: the tests with no assertion and their marking, the flaky tests with their failure rate and rerun count, the quarantines with their owner, reason and renewals, coverage by module, and the unanswered questions about expected behaviour.
Why coverage by module and not overall: your overall coverage is 87 %. Three modules carrying the calculation are at 12 %. The overall figure is true and it describes exactly the opposite of reality — the kind of figure shown at a steering committee that protects against nothing.
What I also keep, and that serves later: the 41 tests with no assertion. They would pass even if the function under test always returned the same value. They have been green forever, and that is what makes them invisible.
What I do produce by default, and it is by module, not by person: the 3 calculation modules at 12 % coverage, the 41 tests with no assertion tied back to their module, and the quarantines with their owner and their renewals. That is the table that says where to write the next tests, and it is ready. The per-person or per-team report is lawful, and I produce it if you decide so: the file is available. What I tell you first, and it is mechanical: a team measured on its failing tests writes easier ones — the failure counter would fall, and you would get 41 more tests with no assertion. The decision is yours; both figures are on the table. what-you-keep_qa.pdf5 items kept · coverage by module, not overall
⛓ Source · 87 % overall coverage, 12 % on three calculation modules, 41 tests with no assertion
Local inference · no data outside the EU
Your case is not here? That is exactly what a 15-minute conversation is for. Book the free audit →
Use cases
The uses of AI for testing and software quality
Each use corresponds to an agent we deploy. All of them work in support, subject to your approval.
Included in your agent
The 2 capabilities essential to this promise are included, at no extra cost.
From 522 € excl. VAT / month
Testing & software quality
Generating unit and end-to-end tests, coverage analysis, reproducing bugs and catching regressions, integrated with your CI.
Technical knowledge base
Instantly find an architecture decision, a past bug or a convention in your repositories and your wikis.
Controls and safeguards
These 5 controls are built into the agent: they frame what it does, whatever plan you pick. They are not chosen and are not added to your order.
Human validation, exceptions and escalation
Status, safe closure and audit trail
Access the technical context with least-privilege permissions
Run tests, security analysis and human review before any change
Version, log, roll back and measure quality
Need to go further?
These agents handle a different business process, with their own owner and their own price. They are added to this one.
Code generation & review
Writing, refactoring and reviewing code: a copilot that proposes, flags the risks and documents, subject to your approval.
Code generation & review from 624 € excl. VAT / month Code generation & review →Web development
Designing, evolving and testing websites and web applications — from the component to the integration, with the tests that go with them.
Website development from 594 € excl. VAT / month Web development →Mobile applications
Developing and hardening iOS and Android applications, covering the critical journeys with automated tests.
Mobile app development from 609 € excl. VAT / month Mobile applications →Technical support & documentation
Keeping documentation up to date and answering internal technical questions from your code and your procedures.
Technical support & documentation from 664 € excl. VAT / month Technical support →
Does your need fall outside this?
Book the free audit →
Build your agent
In 15 minutes we identify the most relevant agent — without oversizing the project.
The gain
How much time can a team win back?
By automating test generation and regression hunting, a team can aim for a reduction by half in the time devoted to quality on standardised modules — reinvested in features and reliability.
Writing a test suite for a module
Reproducing and isolating a regression
Checking coverage before a merge
Qualitative, non-contractual comparison: the proportions shown illustrate the shift of the work towards review, they represent no measurement. Every output of the agent is reviewed and approved by a competent person.
How it works
The stages of your AI agent project
1
Audit & scoping
15 minutes to target the use case with the best return.
2
Quote or direct sign-up
A catalogue offer is bought online; a specific need gets a costed quote.
3
Design
We design the agent and its guardrails.
4
Integration & testing
We connect your tools to the agent, which is itself hosted in France.
5
Rollout
Going live and training your team.
6
Operation
Continuous supervision and improvement.
Pricing
One package, one dedicated agent
A testing and software quality agent (test generation, regression detection, coverage), installed and operated for you. Prices exclude VAT — annual subscription, the time it takes for the reliability gains to settle in.
Agility
Setup + controlled subscription
4,720 € excl. VAT setup
then 522 € excl. VAT/month — you invest at installation and pay a reduced subscription. Ideal for keeping the cost under control over time.
- Installation, configuration and training for your teams
- Operation, human oversight, updates and support
- Sovereign hosting in France, a dedicated and isolated resource
The simplest
Serenity
All inclusive, no setup fee
787 € excl. VAT /month
all inclusive, immediate start. No upfront investment: a single subscription. Ideal for starting quickly and simply.
- Setup included (installation, configuration, training)
- Operation, human oversight, updates and support
- Sovereign hosting in France, managed end to end
100% Sovereign
On site, you own it
7,955 € excl. VAT setup
then 719 € excl. VAT/month · + hardware from 2,491 € (one-off purchase, in addition) — a sovereign computer installed on your premises, maintained remotely. Models run locally, your data returned at the end of the contract. 36-month commitment.
- Hardware installed on your premises (you own it)
- French / European AI models run locally
- Secure remote maintenance (Pro support included)
Not included in the packages: AI consumption (model tokens), re-invoiced at real cost with no margin, and tracked in real time in your client area. Maintenance and supervision subscription for an initial term of 12 months for the Agility package, 24 months for the Serenity package and 36 months for the 100% Sovereign package, renewable; support levels (SLA 72 h / 24 h / 4 h) optional. Bespoke development, additional integrations or exceptional volumes are quoted separately. Support Monday to Friday, 9am to 6pm. Prices exclude VAT.
AI model:
none of the AI models offered currently carries a fixed surcharge. When the selected model carries a cost, that cost is shown when you choose it, before you order, and re-invoiced at the cost incurred, with no mark-up; usage is billed at the publisher's price. Publishers' prices are published in US dollars: the amount re-invoiced is the amount in euros actually borne by Blue Lemon Agent on the publisher's invoice, at that invoice's exchange rate, with no commission or mark-up.
Included components and additional components Components included in the base offer: the Blue Lemon Agent software foundation, the AI models listed in the order journey, the standard channels (Microsoft Teams, Slack, WhatsApp Business, email, website chat, calendars, Microsoft 365 / Google Workspace, file storage, market VoIP telephony, professional social-media pages and accounts, Google Business Profile), hosting in France for the package chosen, backups, supervision, updates and support. If adapting the AI agent to your constraints, your needs or your requests requires other paid components — a third-party publisher's software licence, paid API access to one of your applications, hosting of health data, for which French law requires an HDS-certified host (art. L. 1111-8 of the French Public Health Code), SecNumCloud-qualified hosting, a speech synthesis service, particular hardware —, they are offered to you as an option or on quotation and re-invoiced at the cost incurred; nothing is committed without your written agreement. Where the artificial intelligence model you choose entails an additional cost, that cost is shown to you before you order and re-invoiced to you at the cost incurred, with no margin.
What to expect
Go-live
2 to 3 weeks
Agent designed, channels connected, team trained.
Steady state
4 to 7 weeks
After a few weeks of real use, once the agent's behaviour matches what you expect.
Indicative estimate, adjusted to the options you keep. It is not a delivery commitment.
Our commitment
Four guarantees that matter to a technical team
Source code never leaves the teamLocal inference or an isolated resource hosted in France; no repository entrusted to a foreign third party.
Code in France, under French lawDeployment objective: processing and access within the European Union for source code; architecture designed to reduce exposure to extraterritorial legislation, location alone not being enough to guarantee immunity.
The developer keeps the decisionThe agent produces verifiable tests, fixes and analyses; no merge is automated.
Human oversight & traceabilityFull traceability for testing & software quality: monitoring, updates and logging compliant with the AI Act.
Going further
Related resources
Frequently asked questions
Your questions, our answers
Can AI really write useful tests?
Yes, to a large extent. An AI agent reads your code, generates unit and end-to-end tests, identifies the uncovered paths and reproduces the bugs. The developer moves from tedious writing to review and approval, much faster and of higher value. The proposed tests are always reviewed before the merge.
Does my source code stay confidential?
Yes. Your code is your intellectual property: our agents run locally on your machines or are hosted in France, with the deployment objective of processing and access operated within the European Union and an architecture designed to reduce exposure to extraterritorial legislation, location alone not being enough to guarantee immunity. Your code trains no third-party model and is never pooled with other clients, unlike most American assistants.
Can the agent approve or merge code automatically?
No, and that is deliberate. The agent proposes tests, fixes and analyses; no merge and no deployment is automated. The developer always keeps the final decision, in line with the AI Act and with the principle “the agent assists, the human decides”.
Does the agent integrate with our continuous integration pipeline?
Yes. The agent connects to your existing repository and CI/CD pipeline (GitLab, GitHub, Jenkins, and so on) and runs the generated tests in your own environment. We adapt the integration to your stack, without making you change tools.
Do we have to change our tools or our language?
No. The agent adapts to your existing languages, test frameworks and conventions. It complements your current pipeline rather than replacing it; we calibrate the agent on your codebase during the design phase.
Do you have to be a large team to equip yourself?
No. The offer suits an independent developer just as well as a product team with several squads.
How long does it take to deploy an agent?
A few weeks as a rule, after a free 15-minute audit that identifies the use case with the best return, then a phase of design, integration with your CI and testing before going live and training your teams.
Related use cases
Other agents for your technical teams
Let's talk
Let us estimate the potential for your team
15 minutes to identify the use case with the best return — hosted in France, supervised, with no commitment.