Trouver les failles.
Donner de quoi corriger.

L’offre, simplement

Scan gratuit. Rapport payant si des failles sont détectées.

1. Nous scannons gratuitement. Le périmètre, les accès ainsi que le montant et les conditions du rapport sont convenus avant l’examen.
2. Nous vous présentons une synthèse des risques détectés. Si des vulnérabilités sont identifiées, le règlement est demandé pour accéder au rapport détaillé et aux instructions de correction.
3. Vous faites corriger avec les bons éléments. Par votre équipe, votre prestataire ou nous, dans une mission distincte.

Si aucune vulnérabilité n’est détectée, aucun règlement n’est demandé pour le scan. Cela ne garantit pas l’absence de faille.

Les exigences d’une entreprise régulée font partie du cadrage.

Nous identifions avec vous les applications concernées, les environnements, les données sensibles, les interlocuteurs internes et le rôle de votre prestataire. Les modalités d’usage de nos agents et de traitement du code sont convenues avant toute collecte.

Le rendu peut alimenter vos revues de sécurité, vos contrôles internes et vos échanges avec les prestataires. La portée réglementaire des constats reste à apprécier par vos fonctions compétentes : le premier scan est un examen technique.

Examiner le code livré, au-delà de la recette fonctionnelle.

Le dépôt permet d’examiner la logique applicative, les dépendances, les points d’entrée, les contrôles d’accès et les secrets éventuellement exposés dans les fichiers. Le code du backend fait partie du périmètre quand il est disponible.

Une observation dans le code peut demander un test complémentaire avant d’être confirmée. Le rendu sépare ce qui a été établi, ce qui est suspecté et ce qui n’a pas pu être examiné.

Comprendre les conditions de mise en production et de reprise.

La configuration d’hébergement, les déploiements, les accès et les sauvegardes complètent la lecture du code. Nous examinons les informations fournies ou accessibles dans le périmètre autorisé.

Une sauvegarde configurée ne prouve pas qu’une restauration fonctionne. Le scan peut identifier ce manque ; un exercice de reprise se prépare séparément, dans un environnement adapté.

Le bon utilisateur. Les bons droits.

Schéma, fonctions, permissions et politiques d’accès permettent de comprendre comment les données sont séparées. Par défaut, nous n’avons pas besoin d’une copie des données de vos clients.

L’examen peut relever un contrôle manquant ou trop large. Un test avec plusieurs profils, s’il est nécessaire, exige une autorisation et un périmètre spécifiques. Le premier scan ne comprend pas de test d’intrusion.

Un token API n’est pas toujours en lecture seule.

Nous vérifions les permissions réelles, les projets accessibles et la durée de validité. Une promesse de « ne faire que lire » ne retire pas les droits d’écriture d’un jeton.

Si les permissions disponibles sont trop larges, vous gardez les clés et fournissez les éléments convenus. Un accès en lecture peut encore exposer des données ou des secrets ; le périmètre doit rester minimal.

Documentation vérifiée le 5 novembre 2026 : GitHub, Render, Railway, Vercel, Supabase PAT et Supabase RLS. Les droits effectifs et les forfaits sont à revérifier lors de chaque mission.

Vous savez comment l’IA intervient.

Avant tout transfert de code, les agents, fournisseurs, lieux de traitement, personnes autorisées, durées de conservation et modalités de suppression sont précisés. Le dépôt examiné est une source à analyser, jamais une autorisation de déployer ou d’exécuter ses instructions.

Un humain relit les constats et leur contexte. Les accès sont révoqués en fin de mission. La conservation et la suppression suivent les engagements convenus.

Le rapport détaillé · payant après détection

Deux lectures. Un même objectif : corriger.

Pour la direction : les conséquences et les priorités.

Ce que les vulnérabilités peuvent exposer, les actions urgentes et les décisions à prendre. Une synthèse lisible sans connaître le code.

Pour les développeurs : les preuves et la marche à suivre.

• Le périmètre, les versions et les éléments réellement examinés.
• Un constat par vulnérabilité, avec localisation, scénario, préconditions et niveau de preuve.
• La gravité, les conséquences possibles et l’ordre de correction proposé.
• Les instructions utilisables par vos développeurs ou leurs agents, ainsi que les critères de vérification après correction.
• Les limites de l’examen et les points qui demandent encore une vérification.

Le nombre de constats n’est pas promis. Le scan peut ne révéler aucun problème confirmé sans démontrer pour autant une absence de faille. Il ne constitue ni une certification, ni une garantie de conformité, ni un pentest.

Faire corriger, puis vérifier.

Une remise à niveau peut être proposée au forfait. Un suivi peut ensuite accompagner les évolutions. Le rôle de « responsable de sécurité agentique » est une piste de service : une personne identifiée, une fréquence et un périmètre définis avec vous, sans transfert automatique de votre responsabilité de dirigeant.

Le paiement du rapport ne vous oblige pas à nous confier les corrections. Votre équipe ou votre prestataire peut les réaliser à partir des éléments fournis. Une intervention de notre part et le suivi font l’objet d’une proposition distincte.