● Offre B2B — Tests & qualité logicielle
L'agent IA des tests & de la qualité logicielle : générer les tests, fiabiliser vos livraisons
Écrire les tests, reproduire un bug, traquer une régression avant la mise en production mobilise une part considérable du temps des équipes — un travail indispensable mais rarement valorisé. Votre agent IA absorbe ce travail répétitif : génération de tests, analyse de couverture, détection des régressions. Hébergé en France — en inférence locale ou ressource isolée — votre code source ne quitte jamais votre environnement. Le développeur garde la main.
Hébergé en France
Code source protégé
RGPD & AI Act : déploiement encadré
Le développeur décide
Mis à jour le
Déployé en quelques semaines
Assistant QA · hébergé en France
Le module de paiement n'a presque pas de tests. Génère une suite pour le service checkout et dis-moi ce qui n'est pas couvert.
Service checkout analysé. Couverture actuelle : 34 %. J'ai généré 18 tests unitaires (calcul du panier, remises, TVA) et 4 tests end-to-end (tunnel complet). 3 chemins non couverts restent risqués : échec de paiement partiel, timeout du prestataire, double soumission du formulaire.
Suite prête à relire et à exécuter en CI — vous validez avant le merge.
⛓ Sourcé · votre dépôt + rapport de couverture existant
Suite prête à relire et à exécuter en CI — vous validez avant le merge.
⛓ Sourcé · votre dépôt + rapport de couverture existant
Le dernier déploiement a cassé quelque chose en prod. Tu peux m'aider à isoler la régression ?
Régression localisée. En comparant les deux dernières livraisons, l'erreur apparaît après le commit qui modifie le calcul des frais de port (arrondi changé de 2 à 0 décimales). Reproduction confirmée par un test ciblé : panier à 49,99 € → frais facturés à 0 € au lieu de 4,90 €.
Je prépare le test de non-régression et une note pour le ticket — à votre validation.
✎ Action · test de non-régression prêt — le développeur valide
Je prépare le test de non-régression et une note pour le ticket — à votre validation.
✎ Action · test de non-régression prêt — le développeur valide
Inférence locale · traitements dans l'UE visés
Code hébergé en France
Souverain par constructionInférence locale ou hébergement France
RGPD & AI Act : déploiement encadréTraçabilité & supervision humaine
Clé en mainConçu, installé et exploité pour vous
Le développeur décideL'agent propose, l'humain valide le merge
✦ En bref
Dans une équipe de développement, un agent Blue Lemon Agent automatise le travail de qualité logicielle — génération de tests unitaires et end-to-end, analyse de couverture, reproduction de bugs, détection des régressions — et s'intègre à votre chaîne d'intégration continue (CI). Il fonctionne en inférence locale ou est hébergé en France : votre code source et votre propriété intellectuelle ne sont jamais exposés à un service étranger, architecture conçue pour réduire l'exposition aux législations extraterritoriales, la localisation ne garantissant pas à elle seule l'immunité. Le temps gagné sur les tests est réinvesti dans la fonctionnalité et la fiabilité. Mise en service en quelques semaines.
100 %
hébergé en France dans l'architecture cible
0
transfert hors UE dans l'architecture cible
8
usages prêts à déployer sur ce périmètre
0
décision prise sans validation humaine
Repères décrivant notre offre, et non des résultats mesurés chez un client. L'ampleur du gain se confirme par un pilote sur votre périmètre.
Le contexte
Pourquoi l'IA intéresse les équipes techniques — et pourquoi elles hésitent
La pression sur les délais de livraison ne cesse de croître, mais la qualité reste non négociable : une régression en production coûte cher. Les tests, eux, sont souvent les premiers sacrifiés faute de temps — et le code en jeu est le cœur de la propriété intellectuelle de l'entreprise.
! L'enjeu
L'équipe est prise entre des cycles de livraison qui accélèrent et une dette de tests qui s'accumule (couverture insuffisante, bugs qui reviennent, régressions découvertes en production). Pourtant, la plupart des assistants IA grand public reviennent à confier tout le code source, l'architecture et les secrets applicatifs à un tiers, souvent hébergé hors d'Europe et soumis au Cloud Act.
✓ Notre réponse
L'IA n'a d'intérêt pour une équipe technique que si elle est souveraine et confidentielle par construction. Inférence locale ou ressource isolée hébergée en France, supervision humaine systématique, décision réservée au développeur : le temps gagné sur les tests ne se paie jamais en code exposé. L'objectif n'est pas de remplacer l'ingénieur, mais de lui rendre du temps pour ce qui compte — la fonctionnalité et la fiabilité.
Le point décisif
La confidentialité du code source : souveraineté & propriété intellectuelle
Votre code est votre actif le plus précieux. Voici comment l'architecture de nos agents le protège, dépôt par dépôt.
Inférence locale
L'agent peut tourner sur une machine de l'équipe : aucune ligne de code ne sort du réseau, rien ne transite par un cloud public.
Hébergement en France
Sinon, une ressource dédiée et isolée, hébergée en France sous droit français — votre code : traitements et accès opérés dans l'Union européenne visés par l'architecture.
Exposition extraterritoriale réduite
Architecture conçue pour réduire l'exposition aux législations extraterritoriales, la localisation ne garantissant pas à elle seule l'immunité pour le code source : notre architecture relève d'une chaîne de sous-traitance et d'accès distants documentés pour la configuration retenue.
La propriété intellectuelle reste chez vous
Votre code n'entraîne aucun modèle tiers, n'est ni mutualisé ni réutilisé : il demeure votre propriété exclusive.
Ressource isolée par projet
Pas de mutualisation des dépôts : un environnement strictement dédié à votre équipe et à votre code.
AI Act : déploiement encadré
Agent strictement en appui ; aucun merge automatique ; traçabilité et supervision humaine de bout en bout.
Ce qui dépend de l'architecture retenue Ces points ne sont pas des garanties générales : ils sont arrêtés déploiement par déploiement, au devis.
- La localisation applicable est celle de l'architecture décrite au devis et vérifiée avant mise en service.
- L'exécution locale n'est annoncée que pour la configuration explicitement décrite et recettée au devis.
- L'isolation applicable dépend du mode de déploiement décrit au devis ; aucune isolation dédiée n'est présumée.
- Les événements journalisés, leur contenu, leur durée de conservation et leurs accès sont définis pour le déploiement retenu.
Pour les bases de code les plus sensibles, l'agent s'intègre derrière votre VPN et vos contrôles d'accès existants. Une seule architecture est conçue pour répondre à la fois au RGPD et à l'exposition extraterritoriale. Conçu pour être déployé dans le respect du RGPD et de l'AI Act, après qualification du traitement, des rôles et des risques propres à votre contexte.
Démonstration
Voyez l'agent au travail
4 situations réelles, prises parmi celles qui reviennent le plus. Choisissez-en une : l'échange se déroule comme il se déroulerait chez vous.
Démonstration écrite à l'avance. Ces échanges illustrent le comportement de l'agent — ses sources, ses refus, ce qu'il laisse à vos équipes. Rien n'est envoyé depuis cette page, aucun modèle n'y est interrogé, et les dossiers cités sont fictifs. C'est précisément ce que nous promettons à vos données.
Les comportements montrés ici — surveillance, règles d'automatisation, routage et relances — sont paramétrés avec vous lors du déploiement, à partir de vos outils, de vos règles et de vos seuils.
Les points d'architecture cités dans ces échanges — localisation, exécution locale, isolation, chiffrement, accès par rôle, journalisation — ne sont pas une garantie attachée à la démonstration : ils sont ceux de l'architecture décrite à votre devis, et vérifiés avant mise en service.
Assistant QA · hébergé en France
Quatre signalements ce matin, et aucun ne concerne un test qui échoue.
· Quarante et un tests passeraient même si la fonction testée renvoyait toujours la même valeur. Ils ne vérifient rien.
· Sept tests instables ont été relancés 312 fois ce trimestre jusqu'à ce qu'ils passent.
· Votre couverture affiche 87 %. Trois modules qui portent les paiements sont à 12 %.
· Trente-quatre modifications de code n'ont touché aucun test. Le comportement a changé, rien ne le vérifie. veille-matin_4-signalements.pdf41 tests qui ne vérifient rien
⛓ Sourcé · 1 240 tests, journal d'exécution, couverture par module, historique des branches
· Quarante et un tests passeraient même si la fonction testée renvoyait toujours la même valeur. Ils ne vérifient rien.
· Sept tests instables ont été relancés 312 fois ce trimestre jusqu'à ce qu'ils passent.
· Votre couverture affiche 87 %. Trois modules qui portent les paiements sont à 12 %.
· Trente-quatre modifications de code n'ont touché aucun test. Le comportement a changé, rien ne le vérifie. veille-matin_4-signalements.pdf41 tests qui ne vérifient rien
⛓ Sourcé · 1 240 tests, journal d'exécution, couverture par module, historique des branches
Des tests qui passeraient quoi qu'il arrive ?
Quarante et un, et ils sont verts depuis toujours — c'est ce qui les rend invisibles.
Ce que je constate : 41 tests n'ont aucune assertion sur le résultat de ce qu'ils appellent. Ils vérifient qu'aucune erreur n'a été levée, et rien d'autre.
Comment je l'ai vérifié, plutôt que supposé : j'ai remplacé mentalement le retour de chaque fonction par une valeur constante. Les 41 tests continuent de passer. C'est un contrôle mécanique, pas un jugement de style.
Ce que ça produit : ils comptent dans la couverture, ils comptent dans le nombre de tests, et ils donnent le sentiment que la fonction est testée. Une équipe qui voit « couvert » ne réécrit pas le test.
Ce que je fais : je les marque « sans assertion de résultat », et je les sors du décompte de couverture que je publie. Votre couverture réelle passe alors de 87 % à 79 %.
Et je ne me contente pas du marquage : pour 29 des 41, l'assertion manquante est évidente depuis la fonction appelée — un retour attendu, une longueur, un statut — et je l'ai écrite ; les douze autres portent une question, parce que le résultat attendu n'est écrit nulle part.
Pourquoi je ne les supprime pas : un test sans assertion vérifie quand même que le code s'exécute — c'est peu, ce n'est pas rien, et le supprimer ferait baisser un chiffre sans rien améliorer. Vingt-neuf relectures, et la couverture réelle remonte pour de bon. 41-tests_87-a-79.pdfIls passent même avec une valeur constante
⛓ Sourcé · 1 240 tests, contrôle par substitution du retour
Ce que je constate : 41 tests n'ont aucune assertion sur le résultat de ce qu'ils appellent. Ils vérifient qu'aucune erreur n'a été levée, et rien d'autre.
Comment je l'ai vérifié, plutôt que supposé : j'ai remplacé mentalement le retour de chaque fonction par une valeur constante. Les 41 tests continuent de passer. C'est un contrôle mécanique, pas un jugement de style.
Ce que ça produit : ils comptent dans la couverture, ils comptent dans le nombre de tests, et ils donnent le sentiment que la fonction est testée. Une équipe qui voit « couvert » ne réécrit pas le test.
Ce que je fais : je les marque « sans assertion de résultat », et je les sors du décompte de couverture que je publie. Votre couverture réelle passe alors de 87 % à 79 %.
Et je ne me contente pas du marquage : pour 29 des 41, l'assertion manquante est évidente depuis la fonction appelée — un retour attendu, une longueur, un statut — et je l'ai écrite ; les douze autres portent une question, parce que le résultat attendu n'est écrit nulle part.
Pourquoi je ne les supprime pas : un test sans assertion vérifie quand même que le code s'exécute — c'est peu, ce n'est pas rien, et le supprimer ferait baisser un chiffre sans rien améliorer. Vingt-neuf relectures, et la couverture réelle remonte pour de bon. 41-tests_87-a-79.pdfIls passent même avec une valeur constante
⛓ Sourcé · 1 240 tests, contrôle par substitution du retour
Comment tu as vu tout ça ? Et tu préviens qui ?
Je regarde ce que vous m'avez ouvert : les tests et leurs assertions, le journal d'exécution avec les relances, la couverture par module, et les modifications de code rapportées aux modifications de test.
Le routage suit ce qui se corrige : un test sans assertion à qui l'a écrit s'il est identifiable, sinon à l'équipe ; un test relancé jusqu'à réussir à l'équipe, avec le nombre de relances — jamais à une personne ; un module critique peu couvert à qui décide des priorités ; une modification sans test signalée sur la branche, avant la fusion.
Avec une relance : avant fusion sur une modification sans test, mensuelle sinon. Puis une synthèse mensuelle : par module et par type de faiblesse, jamais par développeur.
Ce que ça vous donne ce matin : une couverture vraie — 79 % au lieu d'un 87 % que 41 tests sans assertion gonflaient —, sept tests instables identifiés après 312 relances, trois modules de paiement à 12 % remontés à qui fixe les priorités, et 34 modifications de comportement que plus rien ne vérifiait, signalées sur la branche avant la fusion.
Ce que ça vaut en production : un chiffre sur lequel on peut décider, et le temps d'écriture des tests rendu à la fonctionnalité — sur 1 240 tests, la suite d'un module arrive préparée, cas limites compris, et il vous reste à la relire. Vos dépôts ne sortent pas de l'équipe : accès par rôle, journalisé, retiré d'un mot, inférence locale ou ressource isolée hébergée en France, et votre code n'entraîne aucun modèle tiers.
Ce qui reste à vous est un choix, pas une réserve : j'écris les tests depuis la spécification et jamais depuis le comportement actuel, parce qu'un test écrit sur le code existant transforme un bug en exigence. Donnez-moi le comportement attendu des trois modules de paiement — et la suite complète est prête à relire dans la journée.
✎ Cadre · aucun test écrit depuis le comportement actuel, aucune relance
Le routage suit ce qui se corrige : un test sans assertion à qui l'a écrit s'il est identifiable, sinon à l'équipe ; un test relancé jusqu'à réussir à l'équipe, avec le nombre de relances — jamais à une personne ; un module critique peu couvert à qui décide des priorités ; une modification sans test signalée sur la branche, avant la fusion.
Avec une relance : avant fusion sur une modification sans test, mensuelle sinon. Puis une synthèse mensuelle : par module et par type de faiblesse, jamais par développeur.
Ce que ça vous donne ce matin : une couverture vraie — 79 % au lieu d'un 87 % que 41 tests sans assertion gonflaient —, sept tests instables identifiés après 312 relances, trois modules de paiement à 12 % remontés à qui fixe les priorités, et 34 modifications de comportement que plus rien ne vérifiait, signalées sur la branche avant la fusion.
Ce que ça vaut en production : un chiffre sur lequel on peut décider, et le temps d'écriture des tests rendu à la fonctionnalité — sur 1 240 tests, la suite d'un module arrive préparée, cas limites compris, et il vous reste à la relire. Vos dépôts ne sortent pas de l'équipe : accès par rôle, journalisé, retiré d'un mot, inférence locale ou ressource isolée hébergée en France, et votre code n'entraîne aucun modèle tiers.
Ce qui reste à vous est un choix, pas une réserve : j'écris les tests depuis la spécification et jamais depuis le comportement actuel, parce qu'un test écrit sur le code existant transforme un bug en exigence. Donnez-moi le comportement attendu des trois modules de paiement — et la suite complète est prête à relire dans la journée.
✎ Cadre · aucun test écrit depuis le comportement actuel, aucune relance
Tu peux générer des tests pour notre code existant ?
Je peux, et ce serait la pire chose que je puisse faire pour vous.
Ce qu'on me demande : parcourir une fonction et produire les tests qui passent. C'est immédiat et le résultat est vert.
Ce qui se passe alors : chaque défaut existant devient un comportement attendu. Si la fonction arrondit mal, le test vérifie qu'elle arrondit mal. Le jour où quelqu'un corrige, le test échoue — et on corrige le test.
Ce que je fais à la place : je pars de ce que le code est censé faire, tel que vous me l'avez dit — une spécification, un ticket, un commentaire, une règle métier. Et quand je n'ai rien, je le dis et je n'écris pas le test.
Ce que ça donne, mesuré : sur 214 fonctions à couvrir, j'ai produit des tests pour 148. Pour 66, je n'avais aucune source décrivant le comportement voulu — j'ai fourni la liste plutôt que des tests.
Ce que les 66 ont révélé : onze concernaient des règles métier que personne dans l'équipe ne savait énoncer. C'est le résultat le plus utile de cet exercice, et il n'est pas un test. 214-fonctions_66-sans-source.pdf11 règles que personne ne savait énoncer
⛓ Sourcé · 214 fonctions, 148 tests produits, 66 sans source
Ce qu'on me demande : parcourir une fonction et produire les tests qui passent. C'est immédiat et le résultat est vert.
Ce qui se passe alors : chaque défaut existant devient un comportement attendu. Si la fonction arrondit mal, le test vérifie qu'elle arrondit mal. Le jour où quelqu'un corrige, le test échoue — et on corrige le test.
Ce que je fais à la place : je pars de ce que le code est censé faire, tel que vous me l'avez dit — une spécification, un ticket, un commentaire, une règle métier. Et quand je n'ai rien, je le dis et je n'écris pas le test.
Ce que ça donne, mesuré : sur 214 fonctions à couvrir, j'ai produit des tests pour 148. Pour 66, je n'avais aucune source décrivant le comportement voulu — j'ai fourni la liste plutôt que des tests.
Ce que les 66 ont révélé : onze concernaient des règles métier que personne dans l'équipe ne savait énoncer. C'est le résultat le plus utile de cet exercice, et il n'est pas un test. 214-fonctions_66-sans-source.pdf11 règles que personne ne savait énoncer
⛓ Sourcé · 214 fonctions, 148 tests produits, 66 sans source
Et si on te donne juste le code, sans spécification ?
Alors je produis des questions, pas des tests.
Ce que je fournis pour chaque fonction sans source : ce que le code fait aujourd'hui, décrit en une phrase, et les trois ou quatre points où son comportement pourrait être volontaire ou accidentel.
Un exemple, tel quel : « cette fonction renvoie zéro quand la liste est vide. Est-ce le résultat voulu, ou un cas non traité ? Selon la réponse, le test à écrire n'est pas le même — et l'un des deux échouera. »
Ce que j'écris en même temps que la question : les deux tests, un par réponse possible, prêts à fusionner. Celui qui reste dépend d'une phrase, pas d'une journée de travail : la réponse arrive, le bon test entre dans la suite le jour même.
Pourquoi c'est plus utile qu'un test choisi par moi : parce que la réponse existe chez quelqu'un. Sur les 66 questions posées, 55 ont reçu une réponse en moins d'une semaine, souvent en deux lignes. Onze n'en ont pas reçu, et ce sont celles qui comptent.
Pourquoi je ne choisis pas l'interprétation la plus probable pour débloquer la situation : un test écrit sur une supposition a exactement la même couleur verte qu'un test écrit sur une règle — et personne ne saura, dans six mois, lequel des deux il regarde.
Ce que je fais des onze : je les laisse ouvertes, et elles réapparaissent chaque mois tant que personne n'a tranché. C'est la seule chose que je répète. 66-questions_55-reponses.pdfUn test sur supposition a la même couleur verte
⛓ Sourcé · 66 questions posées, 55 réponses obtenues
Ce que je fournis pour chaque fonction sans source : ce que le code fait aujourd'hui, décrit en une phrase, et les trois ou quatre points où son comportement pourrait être volontaire ou accidentel.
Un exemple, tel quel : « cette fonction renvoie zéro quand la liste est vide. Est-ce le résultat voulu, ou un cas non traité ? Selon la réponse, le test à écrire n'est pas le même — et l'un des deux échouera. »
Ce que j'écris en même temps que la question : les deux tests, un par réponse possible, prêts à fusionner. Celui qui reste dépend d'une phrase, pas d'une journée de travail : la réponse arrive, le bon test entre dans la suite le jour même.
Pourquoi c'est plus utile qu'un test choisi par moi : parce que la réponse existe chez quelqu'un. Sur les 66 questions posées, 55 ont reçu une réponse en moins d'une semaine, souvent en deux lignes. Onze n'en ont pas reçu, et ce sont celles qui comptent.
Pourquoi je ne choisis pas l'interprétation la plus probable pour débloquer la situation : un test écrit sur une supposition a exactement la même couleur verte qu'un test écrit sur une règle — et personne ne saura, dans six mois, lequel des deux il regarde.
Ce que je fais des onze : je les laisse ouvertes, et elles réapparaissent chaque mois tant que personne n'a tranché. C'est la seule chose que je répète. 66-questions_55-reponses.pdfUn test sur supposition a la même couleur verte
⛓ Sourcé · 66 questions posées, 55 réponses obtenues
Les 7 tests relancés 312 fois ?
Ils échouent une fois sur six, et on les relance jusqu'à ce qu'ils passent.
Ce que je constate : sept tests ont échoué puis réussi sans qu'aucune ligne de code ne change entre les deux exécutions. Total sur le trimestre : 312 relances.
Ce que ça veut dire : soit le test dépend de quelque chose qu'il ne contrôle pas — une horloge, un ordre d'exécution, une ressource partagée — soit le code lui-même est instable, et le test le détecte correctement. Ces deux cas se ressemblent parfaitement dans le journal.
Pourquoi je ne relance pas : une relance automatique transforme un test qui trouve un vrai défaut en test qui finit toujours par passer, et le défaut part en production. Sur 312 relances, il suffit d'une seule pour que cela arrive une fois.
Ce que je fais : je marque le test comme instable et je le sors de la décision de fusion — il continue de tourner et de rapporter, mais il ne bloque plus rien. Un test qu'on relance jusqu'à réussir ne bloquait déjà rien : il faisait perdre du temps sans protéger.
Ce que j'ai trouvé en cherchant la cause : sur les sept, cinq échouent uniquement quand un autre test touche la même table — c'est une dépendance d'exécution, pas une instabilité du produit. L'isolation est écrite pour les cinq : une base par test, et les 312 relances tombent à zéro. Les deux autres échouent seuls, et ceux-là méritent un regard de développeur.
Ce que je fournis pour chacun : le taux d'échec, les heures des échecs, et ce qui tournait en parallèle. 7-tests_312-relances.pdf5 sur 7 échouent sur la même table
⛓ Sourcé · 7 tests, 312 relances, journal d'exécution parallèle
Ce que je constate : sept tests ont échoué puis réussi sans qu'aucune ligne de code ne change entre les deux exécutions. Total sur le trimestre : 312 relances.
Ce que ça veut dire : soit le test dépend de quelque chose qu'il ne contrôle pas — une horloge, un ordre d'exécution, une ressource partagée — soit le code lui-même est instable, et le test le détecte correctement. Ces deux cas se ressemblent parfaitement dans le journal.
Pourquoi je ne relance pas : une relance automatique transforme un test qui trouve un vrai défaut en test qui finit toujours par passer, et le défaut part en production. Sur 312 relances, il suffit d'une seule pour que cela arrive une fois.
Ce que je fais : je marque le test comme instable et je le sors de la décision de fusion — il continue de tourner et de rapporter, mais il ne bloque plus rien. Un test qu'on relance jusqu'à réussir ne bloquait déjà rien : il faisait perdre du temps sans protéger.
Ce que j'ai trouvé en cherchant la cause : sur les sept, cinq échouent uniquement quand un autre test touche la même table — c'est une dépendance d'exécution, pas une instabilité du produit. L'isolation est écrite pour les cinq : une base par test, et les 312 relances tombent à zéro. Les deux autres échouent seuls, et ceux-là méritent un regard de développeur.
Ce que je fournis pour chacun : le taux d'échec, les heures des échecs, et ce qui tournait en parallèle. 7-tests_312-relances.pdf5 sur 7 échouent sur la même table
⛓ Sourcé · 7 tests, 312 relances, journal d'exécution parallèle
La couverture à 87 % avec des modules à 12 % ?
Le chiffre global est vrai, et il décrit exactement le contraire de la réalité.
Ce que je constate : couverture globale 87 %. Trois modules qui portent le calcul et l'enregistrement des paiements : 12 %, 19 % et 24 %. Ce qui tire la moyenne, ce sont les modules d'affichage, couverts à 96 %.
Pourquoi c'est le sens même de l'indicateur : on couvre facilement ce qui est simple, et un module d'affichage est plus simple à tester qu'un calcul de prorata. Une équipe qui optimise sa couverture teste donc en priorité ce qui casse le moins.
Ce que je ne publie pas : le taux global. Il n'a aucune valeur d'information — deux logiciels à 87 % peuvent être dans des états opposés.
Ce que je publie à la place : la couverture des modules que vous m'avez désignés comme critiques, et rien d'autre. Trois chiffres, pas un.
Ce que je propose : que la liste des modules critiques soit écrite par vous, pas déduite par moi. J'ai proposé une liste de sept d'après les incidents passés ; vous en avez retenu cinq et ajouté deux auxquels je n'avais pas pensé. 87-pourcent_3-modules-a-12.pdfOn couvre facilement ce qui est simple
⛓ Sourcé · couverture par module, liste des modules critiques
Ce que je constate : couverture globale 87 %. Trois modules qui portent le calcul et l'enregistrement des paiements : 12 %, 19 % et 24 %. Ce qui tire la moyenne, ce sont les modules d'affichage, couverts à 96 %.
Pourquoi c'est le sens même de l'indicateur : on couvre facilement ce qui est simple, et un module d'affichage est plus simple à tester qu'un calcul de prorata. Une équipe qui optimise sa couverture teste donc en priorité ce qui casse le moins.
Ce que je ne publie pas : le taux global. Il n'a aucune valeur d'information — deux logiciels à 87 % peuvent être dans des états opposés.
Ce que je publie à la place : la couverture des modules que vous m'avez désignés comme critiques, et rien d'autre. Trois chiffres, pas un.
Ce que je propose : que la liste des modules critiques soit écrite par vous, pas déduite par moi. J'ai proposé une liste de sept d'après les incidents passés ; vous en avez retenu cinq et ajouté deux auxquels je n'avais pas pensé. 87-pourcent_3-modules-a-12.pdfOn couvre facilement ce qui est simple
⛓ Sourcé · couverture par module, liste des modules critiques
À chaque nouveau développeur, on réexplique les mêmes règles de test. Tu peux faire quelque chose ?
La base de connaissances technique de votre chaîne de tests est écrite, et elle est adossée à vos exécutions, pas à une bonne pratique générale.
Ce qu'elle contient : 34 fiches, chacune tirée d'un cas réellement survenu chez vous — les 41 tests sans assertion et le contrôle mécanique qui les détecte, la règle de quarantaine avec sa date et son propriétaire, les sept tests instables avec ce qui les rend instables (une horloge, un ordre d'exécution, une ressource partagée), et pourquoi la couverture se lit par module quand la globale dit 87 % et le module de paiement 12 %.
Ce qui la sépare d'un guide de bonnes pratiques : chaque fiche cite l'exécution datée qui l'a produite. Une règle sans incident derrière elle n'entre pas dans cette base de connaissances : elle serait discutée à la première urgence, et elle perdrait.
Ce qu'elle a déjà changé : sur les 19 branches ouvertes depuis sa mise à disposition, 3 tests sans assertion ont été écrits contre 11 sur les 19 branches précédentes. Le chiffre honnête est 3, pas 0 : la base de connaissances technique réduit, elle ne supprime pas.
Ce que je propose ensuite : lier chaque fiche au contrôle qui la fait respecter, pour que la règle vive dans la chaîne et pas seulement dans un texte — 4 des 34 fiches n'ont aujourd'hui aucun contrôle en face, et je vous dis lesquelles.
⛓ Sourcé · 34 fiches adossées à des exécutions datées, 3 tests sans assertion sur 19 branches contre 11
Ce qu'elle contient : 34 fiches, chacune tirée d'un cas réellement survenu chez vous — les 41 tests sans assertion et le contrôle mécanique qui les détecte, la règle de quarantaine avec sa date et son propriétaire, les sept tests instables avec ce qui les rend instables (une horloge, un ordre d'exécution, une ressource partagée), et pourquoi la couverture se lit par module quand la globale dit 87 % et le module de paiement 12 %.
Ce qui la sépare d'un guide de bonnes pratiques : chaque fiche cite l'exécution datée qui l'a produite. Une règle sans incident derrière elle n'entre pas dans cette base de connaissances : elle serait discutée à la première urgence, et elle perdrait.
Ce qu'elle a déjà changé : sur les 19 branches ouvertes depuis sa mise à disposition, 3 tests sans assertion ont été écrits contre 11 sur les 19 branches précédentes. Le chiffre honnête est 3, pas 0 : la base de connaissances technique réduit, elle ne supprime pas.
Ce que je propose ensuite : lier chaque fiche au contrôle qui la fait respecter, pour que la règle vive dans la chaîne et pas seulement dans un texte — 4 des 34 fiches n'ont aujourd'hui aucun contrôle en face, et je vous dis lesquelles.
⛓ Sourcé · 34 fiches adossées à des exécutions datées, 3 tests sans assertion sur 19 branches contre 11
Tu peux désactiver un test qui bloque une livraison ?
Oui — en quarantaine datée, avec un propriétaire, et il revient tout seul. C'est ce qui distingue une décision d'un oubli.
Ce que je fais quand vous me le demandez : je mets le test en quarantaine, pas en « ignoré ». La différence tient en trois attributs : une date de réactivation, un nom, et le motif écrit au moment où on décide — pas reconstitué trois mois plus tard.
Ce qui se passe ensuite, sans que personne y pense : à l'échéance, le test se réactive. S'il échoue encore, il repart en quarantaine et le compteur de reconductions s'affiche. Un test reconduit quatre fois n'est plus une livraison urgente : c'est une décision de ne pas corriger, et elle se voit.
Pourquoi c'est mieux que de refuser : parce qu'un refus se contourne. La ligne qui marque un test comme ignoré prend deux secondes à écrire à la main, un vendredi à 19 h, et personne ne la retrouve. La quarantaine, elle, est plus rapide que le contournement et laisse une trace.
Ce que je signale au passage : vos 7 tests relancés 312 fois — ils échouent une fois sur six sans qu'aucune ligne ne change. Ce sont eux qu'on désactive un vendredi, et la quarantaine les rend enfin visibles comme un sujet à traiter. quarantaine-datee_plutot-que-ignore.pdf3 attributs · la réactivation automatique · le compteur de reconductions
⛓ Sourcé · 7 tests instables, 312 relances, quarantaine datée avec compteur
Ce que je fais quand vous me le demandez : je mets le test en quarantaine, pas en « ignoré ». La différence tient en trois attributs : une date de réactivation, un nom, et le motif écrit au moment où on décide — pas reconstitué trois mois plus tard.
Ce qui se passe ensuite, sans que personne y pense : à l'échéance, le test se réactive. S'il échoue encore, il repart en quarantaine et le compteur de reconductions s'affiche. Un test reconduit quatre fois n'est plus une livraison urgente : c'est une décision de ne pas corriger, et elle se voit.
Pourquoi c'est mieux que de refuser : parce qu'un refus se contourne. La ligne qui marque un test comme ignoré prend deux secondes à écrire à la main, un vendredi à 19 h, et personne ne la retrouve. La quarantaine, elle, est plus rapide que le contournement et laisse une trace.
Ce que je signale au passage : vos 7 tests relancés 312 fois — ils échouent une fois sur six sans qu'aucune ligne ne change. Ce sont eux qu'on désactive un vendredi, et la quarantaine les rend enfin visibles comme un sujet à traiter. quarantaine-datee_plutot-que-ignore.pdf3 attributs · la réactivation automatique · le compteur de reconductions
⛓ Sourcé · 7 tests instables, 312 relances, quarantaine datée avec compteur
Qu'est-ce que tu gardes de tout ça ?
Ce qui décrit l'état réel de la chaîne — et ce qui empêche un chiffre flatteur de tenir lieu de qualité.
Ce qui est conservé : les tests sans assertion et leur marquage, les tests instables avec leur taux d'échec et leur nombre de relances, les quarantaines avec leur propriétaire, leur motif et leurs reconductions, la couverture par module, et les questions restées sans réponse sur le comportement attendu.
Pourquoi la couverture par module et pas la globale : votre couverture globale est de 87 %. Trois modules qui portent le calcul sont à 12 %. Le chiffre global est vrai et il décrit exactement le contraire de la réalité — c'est le genre de chiffre qu'on affiche en comité et qui ne protège de rien.
Ce que je garde aussi, et qui sert plus tard : les 41 tests sans assertion. Ils passeraient même si la fonction testée renvoyait toujours la même valeur. Ils sont verts depuis toujours, et c'est ce qui les rend invisibles.
Ce que je produis par défaut, et c'est par module, pas par personne : les 3 modules du calcul à 12 % de couverture, les 41 tests sans assertion rattachés à leur module, et les quarantaines avec leur propriétaire et leurs reconductions. C'est le tableau qui dit où écrire les prochains tests, et il est prêt. Le relevé par personne ou par équipe est licite, et je le sors si vous le décidez : le dossier est disponible. Ce que je vous dis avant, et c'est mécanique : une équipe mesurée sur ses tests en échec en écrit de plus faciles — le compteur d'échecs baisserait, et vous obtiendriez 41 tests sans assertion de plus. La décision vous revient ; les deux chiffres sont sur la table. ce-que-vous-gardez_qa.pdf5 données gardées · la couverture par module, pas la globale
⛓ Sourcé · couverture 87 % globale, 12 % sur trois modules de calcul, 41 tests sans assertion
Ce qui est conservé : les tests sans assertion et leur marquage, les tests instables avec leur taux d'échec et leur nombre de relances, les quarantaines avec leur propriétaire, leur motif et leurs reconductions, la couverture par module, et les questions restées sans réponse sur le comportement attendu.
Pourquoi la couverture par module et pas la globale : votre couverture globale est de 87 %. Trois modules qui portent le calcul sont à 12 %. Le chiffre global est vrai et il décrit exactement le contraire de la réalité — c'est le genre de chiffre qu'on affiche en comité et qui ne protège de rien.
Ce que je garde aussi, et qui sert plus tard : les 41 tests sans assertion. Ils passeraient même si la fonction testée renvoyait toujours la même valeur. Ils sont verts depuis toujours, et c'est ce qui les rend invisibles.
Ce que je produis par défaut, et c'est par module, pas par personne : les 3 modules du calcul à 12 % de couverture, les 41 tests sans assertion rattachés à leur module, et les quarantaines avec leur propriétaire et leurs reconductions. C'est le tableau qui dit où écrire les prochains tests, et il est prêt. Le relevé par personne ou par équipe est licite, et je le sors si vous le décidez : le dossier est disponible. Ce que je vous dis avant, et c'est mécanique : une équipe mesurée sur ses tests en échec en écrit de plus faciles — le compteur d'échecs baisserait, et vous obtiendriez 41 tests sans assertion de plus. La décision vous revient ; les deux chiffres sont sur la table. ce-que-vous-gardez_qa.pdf5 données gardées · la couverture par module, pas la globale
⛓ Sourcé · couverture 87 % globale, 12 % sur trois modules de calcul, 41 tests sans assertion
Inférence locale · traitements dans l'UE visés
Votre cas n'est pas ici ? C'est exactement ce dont on parle en 15 minutes. Réserver l'audit gratuit →
Cas d'usage
Les usages de l'IA pour les tests et la qualité logicielle
Chaque usage correspond à un agent que nous déployons. Tous fonctionnent en appui, sous votre validation.
Inclus dans votre agent
Les 2 capacités essentielles à cette promesse sont comprises, sans surcoût.
À partir de 522 € HT / mois
Tests & qualité logicielle
Génération de tests unitaires et end-to-end, analyse de couverture, reproduction de bugs et détection des régressions, intégrés à votre CI.
Base de connaissances technique
Retrouver instantanément une décision d'architecture, un bug passé ou une convention dans vos dépôts et vos wikis.
Contrôles et garanties
Ces 5 contrôles sont intégrés à l'agent : ils encadrent ce qu'il fait, quelle que soit la formule retenue. Ils ne se choisissent pas et ne s'ajoutent pas à votre commande.
Validation humaine, exceptions et escalade
Statut, clôture sûre et traçabilité
Accéder au contexte technique avec permissions minimales
Exécuter tests, analyse de sécurité et revue humaine avant changement
Versionner, journaliser, revenir en arrière et mesurer la qualité
Besoin d'aller plus loin ?
Ces agents traitent un autre processus métier, avec leur propre responsable et leur propre tarif. Ils s'ajoutent à celui-ci.
Génération & revue de code
Écrire, refactoriser et relire le code : un copilote qui propose, signale les risques et documente, sous votre validation.
Génération & revue de code dès 624 € HT / mois Génération & revue de code →Développement web
Concevoir, faire évoluer et tester des sites et applications web — du composant à l'intégration, avec les tests qui vont avec.
Développement de sites web dès 594 € HT / mois Développement web →Applications mobiles
Développer et fiabiliser des applications iOS et Android, en couvrant les parcours critiques par des tests automatisés.
Développement d'applications mobiles dès 609 € HT / mois Applications mobiles →Support technique & documentation
Maintenir une documentation à jour et répondre aux questions techniques internes à partir de votre code et de vos procédures.
Support technique & documentation dès 664 € HT / mois Support technique →
Votre besoin sort du cadre ?
Réserver l'audit gratuit →
Composer votre agent
En 15 minutes, nous identifions l'agent le plus pertinent — sans surdimensionner le projet.
Le gain
Combien de temps une équipe peut-elle récupérer ?
En automatisant la génération des tests et la traque des régressions, une équipe peut viser une réduction de moitié du temps consacré à la qualité sur les modules standardisés — réinvesti dans la fonctionnalité et la fiabilité.
Écriture d'une suite de tests sur un module
Reproduire et isoler une régression
Vérifier la couverture avant un merge
Comparaison qualitative, non contractuelle : les proportions affichées illustrent le déplacement du travail vers la relecture, elles ne représentent aucune mesure. Chaque production de l'agent est relue et validée par une personne compétente.
Comment ça se passe
Les étapes de votre projet d'agent IA
1
Audit & cadrage
15 min pour cibler le cas d'usage le plus rentable.
2
Devis ou souscription directe
Une offre du catalogue se souscrit en ligne ; un besoin particulier reçoit un devis chiffré.
3
Conception
Nous concevons l'agent et ses garde-fous.
4
Intégration & tests
Nous raccordons vos outils à l'agent, lui-même hébergé en France.
5
Déploiement
Mise en service et formation de votre équipe.
6
Exploitation
Supervision continue et amélioration.
Tarifs
Une formule, un agent dédié
Un agent de tests et de qualité logicielle (génération de tests, détection de régressions, couverture), installé et exploité pour vous. Tarifs HT — abonnement annuel, le temps que les gains de fiabilité s'installent durablement.
Agilité
Installation + abonnement maîtrisé
4 720 € HT de mise en service
puis 522 € HT/mois — vous investissez à l'installation et payez un abonnement réduit. Idéal pour maîtriser le coût dans la durée.
- Installation, paramétrage et formation de vos équipes
- Exploitation, supervision humaine, mises à jour et support
- Hébergement souverain en France, ressource dédiée et isolée
Le plus simple
Sérénité
Tout inclus, sans frais d'installation
787 € HT /mois
tout compris, démarrage immédiat. Aucun investissement de départ : un abonnement unique. Idéal pour démarrer vite, en toute simplicité.
- Mise en service incluse (installation, paramétrage, formation)
- Exploitation, supervision humaine, mises à jour et support
- Hébergement souverain en France, géré de bout en bout
100 % Souverain
Sur site, vous êtes propriétaire
7 955 € HT de mise en service
puis 719 € HT/mois · + matériel dès 2 491 € (achat unique, en sus) — ordinateur souverain installé chez vous, maintenu à distance. Modèles en local, vos données restituées à la fin du contrat. Engagement 36 mois.
- Matériel installé dans vos locaux (vous en êtes propriétaire)
- Modèles IA français / européens exécutés en local
- Maintenance à distance sécurisée (Suivi Pro inclus)
Non inclus dans les formules : la consommation d'IA (jetons « tokens » des modèles), refacturée au coût réel, sans marge, et suivie en temps réel dans votre espace client. Abonnement de maintenance et de supervision sur une durée initiale de 12 mois pour la formule Agilité, de 24 mois pour la formule Sérénité et de 36 mois pour la formule 100 % Souverain, renouvelable ; niveaux de Suivi (SLA 72 h / 24 h / 4 h) en option. Les développements sur-mesure, intégrations supplémentaires ou volumétries exceptionnelles font l'objet d'un devis. Support du lundi au vendredi, de 9h à 18h. Tarifs hors taxes (HT).
Modèle d'IA :
aucun des modèles d'IA proposés n'entraîne aujourd'hui de supplément fixe. Lorsque le modèle retenu entraîne un coût, ce coût est indiqué au moment du choix, avant la commande, et refacturé au coût constaté, sans marge ; la consommation est facturée au prix de l'éditeur. Les prix des éditeurs sont publiés en dollars américains : le montant refacturé est le montant en euros effectivement supporté par Blue Lemon Agent sur la facture de l'éditeur, au taux de cette facture, sans commission ni majoration.
Composants inclus et composants complémentaires Composants inclus dans l'offre de base : le socle logiciel Blue Lemon Agent, les modèles d'IA de la liste du tunnel de commande, les canaux standards (Microsoft Teams, Slack, WhatsApp Business, courriel, chat du site, agendas, Microsoft 365 / Google Workspace, stockage de fichiers, téléphonie sur IP du marché, pages et comptes professionnels des réseaux sociaux, fiche d'établissement Google), l'hébergement en France de la formule choisie, les sauvegardes, la supervision, les mises à jour et le support. Si l'adaptation de l'agent IA à vos contraintes, à vos besoins ou à vos demandes exige la mise en place d'autres composants payants — licence logicielle d'un éditeur tiers, accès API payant à l'un de vos logiciels, hébergement de données de santé, qui impose en France un hébergeur certifié HDS (art. L. 1111-8 du Code de la santé publique), hébergement qualifié SecNumCloud, service de synthèse vocale, matériel particulier —, ils vous sont proposés en option ou sur devis et refacturés au coût constaté ; rien n'est engagé sans votre accord écrit. Lorsque le modèle d'intelligence artificielle que vous retenez entraîne un coût supplémentaire, ce coût vous est indiqué avant votre commande et vous est refacturé au coût constaté, sans marge.
Ce que vous pouvez attendre
Mise en service
2 à 3 semaines
Agent conçu, canaux raccordés, équipe formée.
Régime nominal
4 à 7 semaines
Après quelques semaines d'usage réel, le temps que le comportement de l'agent soit ajusté à ce que vous attendez.
Estimation indicative, ajustée selon les options que vous retenez. Elle n'est pas un engagement de délai.
Notre engagement
Quatre garanties qui comptent pour une équipe technique
Le code source ne sort jamais de l'équipeInférence locale ou ressource isolée hébergée en France ; aucun dépôt confié à un tiers étranger.
Code en France, sous droit françaisObjectif de déploiement : traitements et accès dans l'Union européenne pour le code source ; architecture conçue pour réduire l'exposition aux législations extraterritoriales, la localisation ne garantissant pas à elle seule l'immunité.
Le développeur garde la décisionL'agent produit tests, correctifs et analyses vérifiables ; aucun merge n'est automatisé.
Supervision humaine & traçabilitéTraçabilité complète pour tests & qualité logicielle : monitoring, mises à jour et journalisation conformes à l'AI Act.
Aller plus loin
Ressources liées
Questions fréquentes
Vos questions, nos réponses
L'IA peut-elle vraiment écrire des tests utiles ?
Oui en grande partie. Un agent IA lit votre code, génère des tests unitaires et end-to-end, identifie les chemins non couverts et reproduit les bugs. Le développeur passe d'un rôle d'écriture fastidieuse à un rôle de relecture et de validation, beaucoup plus rapide et à plus forte valeur. Les tests proposés sont toujours relus avant le merge.
Mon code source reste-t-il confidentiel ?
Oui. Votre code est votre propriété intellectuelle : nos agents fonctionnent en local sur vos machines ou sont hébergés en France, avec pour objectif de déploiement des traitements et des accès opérés dans l'Union européenne et une architecture conçue pour réduire l'exposition aux législations extraterritoriales, la localisation ne garantissant pas à elle seule l'immunité. Votre code n'entraîne aucun modèle tiers et n'est jamais mutualisé avec d'autres clients, contrairement à la plupart des assistants américains.
L'agent peut-il valider ou fusionner du code automatiquement ?
Non, et c'est volontaire. L'agent propose des tests, des correctifs et des analyses ; aucun merge ni aucun déploiement n'est automatisé. Le développeur garde systématiquement la décision finale, conformément à l'AI Act et au principe « l'agent assiste, l'humain décide ».
L'agent s'intègre-t-il à notre chaîne d'intégration continue (CI) ?
Oui. L'agent se connecte à votre dépôt et à votre pipeline CI/CD existants (GitLab, GitHub, Jenkins, etc.) et exécute les tests générés dans votre environnement. Nous adaptons l'intégration à votre stack, sans imposer de changement d'outils.
Faut-il changer nos outils ou notre langage ?
Non. L'agent s'adapte à vos langages, vos frameworks de test et vos conventions existants. Il vient compléter votre chaîne actuelle, pas la remplacer ; nous calibrons l'agent sur votre base de code lors de la phase de conception.
Faut-il être une grande équipe pour s'équiper ?
Non. L'offre s'adapte aussi bien au développeur indépendant qu'à l'équipe produit à plusieurs squads.
Combien de temps pour déployer un agent ?
Quelques semaines en général, après un audit gratuit de 15 minutes qui identifie le cas d'usage le plus rentable, puis une phase de conception, d'intégration à votre CI et de tests avant la mise en service et la formation de vos équipes.
Cas d'usage liés
D'autres agents pour vos équipes techniques
Parlons-en
Estimons le potentiel pour votre équipe
15 minutes pour identifier le cas d'usage le plus rentable — hébergé en France, supervisé, sans engagement.