Audit de sécurité : tests, rapport, validation, puis correctifs

Nous testons votre application sur un périmètre signé — connexion, droits entre utilisateurs, base de données, API, secrets, dépendances, fonctions IA —, puis vous remettons un rapport priorisé en langage clair. Après votre validation, nous appliquons les correctifs choisis et retestons chaque point. Rien n’est modifié sans votre accord.

Un audit de sécurité n’est pas un scanner lancé un vendredi soir. C’est une méthode : comprendre l’application, la regarder comme un attaquant le ferait, prouver chaque faille et écrire ce qu’il faut faire. Nous l’avons conçu pour des créateurs qui n’ont pas de responsable sécurité — fondateurs, indépendants, PME qui ont fait construire un outil par l’IA.

La différence avec un cabinet classique : le rapport n’est pas la fin. Vous pouvez nous demander d’appliquer les correctifs, avec un devis fermé établi à partir de ce que vous avez validé.

Le déroulé

  1. 1 — Cadrage

    Périmètre et autorisation

    Appel de 30 minutes : ce que fait l’application, quelles données elle manipule, ce qui est dans le périmètre. Nous signons l’autorisation de test, la confidentialité et les créneaux.

  2. 2 — Tests

    La batterie de tests

    Authentification et sessions ; droits d’accès entre utilisateurs et entre rôles ; base de données et règles d’accès ; API et validation des entrées ; secrets, clés et configuration ; dépendances vulnérables ; abus de fonctionnalités (paiement, e-mails, uploads) ; sécurité des fonctions IA.

  3. 3 — Rapport

    Rapport et restitution

    Un rapport lisible par un non-technicien en première partie, détaillé pour votre développeur en seconde. Restitution orale d’une heure pour répondre aux questions.

  4. 4 — Validation

    Vous décidez

    Vous cochez ce qui est corrigé maintenant, plus tard, ou accepté comme risque. Le devis de correction est forfaitaire et établi sur cette base.

  5. 5 — Correctifs

    Implémentation et retest

    Correctifs appliqués sur une branche, relus avec vous, puis retest de chaque constat. Attestation de retest remise, utile pour un client B2B ou un investisseur.

Ce que vous recevez

  • Un résumé exécutif d’une page : le risque réel, en langage clair
  • La liste des constats, classés critique / élevé / moyen / faible / informatif
  • Pour chaque constat : preuve reproductible, impact sur votre activité, correctif, effort estimé
  • Les points testés sans rien trouver, pour que vous sachiez ce qui est couvert
  • Un plan de correction ordonné
  • L’attestation de retest après correctifs

Nos règles de conduite

Autorisation écrite avant tout test

Piratage informatique = infraction. Sans signature du propriétaire, nous ne testons pas.

Non destructif par défaut

Pas de suppression de données, pas de charge excessive, pas d’exfiltration de données réelles : une preuve minimale suffit.

Confidentialité

Vos failles ne sont jamais publiées ni citées sans accord écrit ; les études de cas sont anonymisées.

Honnêteté sur les limites

Le rapport précise ce qui n’a pas été testé. Nous ne promettons pas « 100 % sécurisé ».

Ce que l’audit n’est pas

  • Une certification : aucune norme ISO 27001 ni attestation réglementaire n’en découle.
  • Une garantie d’absence de faille : un test est une photographie, l’application évolue.
  • Une attaque par déni de service ou par ingénierie sociale : hors périmètre sauf accord spécifique.
  • Un test d’infrastructure interne, de réseau d’entreprise ou de systèmes industriels.

Questions fréquentes

Combien de temps dure un audit ?

Un audit flash prend en général trois à cinq jours ouvrés pour une application simple ; un audit complet deux à trois semaines selon le nombre de rôles utilisateurs et la taille de l’API. Le calendrier est fixé par écrit avec le périmètre.

Mon application peut-elle tomber pendant les tests ?

Les tests sont conçus pour être non destructeurs et sont menés à un rythme limité, de préférence sur une préproduction avec des données fictives. Les opérations qui présentent un risque (suppression, charge) sont listées, discutées et n’ont lieu qu’avec votre accord explicite.

Que se passe-t-il si vous trouvez une faille grave ?

Nous vous prévenons immédiatement, sans attendre le rapport, par le canal convenu : une clé exposée ou une base ouverte ne se discute pas. Les détails restent confidentiels et ne sont jamais publiés sans votre accord.

Faut-il un contrat ?

Oui, c’est la condition légale et pratique : une autorisation de test écrite signée par le propriétaire du système (ou son représentant), précisant périmètre, dates, adresses IP sources et contacts d’urgence, accompagnée d’une clause de confidentialité.