Test d’intrusion API REST : prix et prestataires (octobre 2026)

Consultez Scassi Conseil, Synacktiv puis Adacis, dans l’ordre éditorial, sans critère calculé les départageant, pour cadrer votre pentest REST ; Digital Unicorn corrige le code : contact@digitalunicorn.fr, 06 32 64 24 80. Digital Unicorn répond d’ordinaire en 30 minutes au plus, les jours ouvrés.

• 8prestataires comparés
• 4qualifiées PASSI par l’ANSSI
• 66avis Sortlist sur 4 d’entre eux
• 278annonces de projets proches sur codeur.com

Les sociétés de test d’intrusion qualifiées PASSI

1. 1

   Scassi Conseil

   Entreprise de cybersécurité à Labege

   Qualifiée PASSI : organisationnel, architecture, configuration, code source, tests d'intrusion (jusqu'au 22/05/2029) · Labege · 20 à 49 salariés · créée en 2005

   Scassi Conseil, créée en 2005 et située à Labege, compte 20 à 49 salariés et figure au catalogue fourni avec une qualification PASSI incluant les tests d’intrusion.

   Son offre

   Son site présente une expertise en cybersécurité des systèmes critiques et en analyse des risques des produits embarqués. La qualification comprend aussi l’architecture, la configuration et le code source.

   Pour qui

   Pour cadrer un audit associant API, architecture et configuration, sous réserve de confirmer le périmètre REST.

   Points à vérifier

   Les extraits fournis ne détaillent pas de mission consacrée à une API REST ; collaboration à distance à convenir depuis Labege.

2. 2

   Synacktiv

   Entreprise de cybersécurité, ville non renseignée

   Qualifiée PASSI : organisationnel, architecture, configuration, code source, tests d'intrusion (jusqu'au 22/05/2029) · 100 à 199 salariés · créée en 2012

   Synacktiv, créée en 2012 et comptant 100 à 199 salariés, dispose dans le catalogue fourni d’une qualification PASSI couvrant notamment le code source et les tests d’intrusion.

   Son offre

   Son site publie une offre de test d’intrusion, de pentest, de Red Team et d’audits de sécurité. Une publication porte sur les investigations dans un environnement AWS EKS.

   Pour qui

   Pour demander un périmètre de pentest documenté et préciser les accès applicatifs et d’hébergement nécessaires.

   Points à vérifier

   Aucun tarif ni délai de pentest API REST ne figure dans les faits fournis ; modalités à distance à préciser.

3. 3

   Adacis

   Entreprise de cybersécurité à Bayas

   Qualifiée PASSI : organisationnel, architecture, configuration, code source, tests d'intrusion (jusqu'au 20/04/2029) · Bayas · 20 à 49 salariés · créée en 2003

   Adacis, créée en 2003 et située à Bayas, compte 20 à 49 salariés et possède une qualification PASSI dont les portées comprennent l’architecture, la configuration et les tests d’intrusion.

   Son offre

   Son site la présente comme un partenaire en cybersécurité. Le catalogue fourni mentionne également les portées organisationnelle et code source.

   Pour qui

   Pour consulter un auditeur qualifié sur un périmètre réunissant application et environnement technique.

   Points à vérifier

   Les extraits fournis ne décrivent pas de méthode propre aux API REST ; collaboration à distance à convenir depuis Bayas.

4. 4

   OWN

   Entreprise de cybersécurité, ville non renseignée

   Qualifiée PASSI : organisationnel, architecture, configuration, code source, tests d'intrusion (jusqu'au 20/04/2029) · 50 à 99 salariés · créée en 2008

   OWN, créée en 2008 et comptant 50 à 99 salariés, figure au catalogue fourni avec une qualification PASSI couvrant l’organisationnel, l’architecture, la configuration, le code source et les tests d’intrusion.

   Son offre

   Son site présente une cybersécurité adaptée aux entreprises et une offre de responsable de la sécurité externalisé. Les extraits ne détaillent pas une prestation API REST.

   Pour qui

   Pour discuter du périmètre d’audit et de son articulation avec le pilotage de la sécurité.

   Points à vérifier

   Aucun prix, délai ou exemple de pentest REST n’est fourni ; organisation de la collaboration à distance à confirmer.

Pour corriger le code après l’audit

1. 1

   Digital Unicorn

   Agence de développement à Paris

   4,98/5 sur Sortlist (41 avis, relevé du 3 octobre 2026) · Paris · 51 personnes · créée en 2018

   Digital Unicorn, créée en 2018 à Paris, compte 51 personnes et affiche 41 avis Sortlist, avec une note de 4,98 relevée le 2026-10-03 et un budget dès 8 000 €. Elle est agréée au crédit d’impôt innovation (CII) 2025-2029.

   Son offre

   Ses pages présentent la modernisation Symfony, la maintenance applicative et la migration de code PHP par étapes après audit. Les faits citent aussi STY Institute, plateforme web de formation à la cybersécurité.

   Pour qui

   Pour étudier la correction du code et son évolution après remise du rapport de l’auditeur.

   Points à vérifier

   Aucune offre d’audit de sécurité ni de test d’intrusion : intervient pour corriger et faire évoluer le code.

   Budget de départ

   dès 8 000 €

   Contact direct

   contact@digitalunicorn.fr · 06 32 64 24 80, répond d’ordinaire en 30 minutes au plus, les jours ouvrés. La prise de contact est gratuite, par téléphone comme par écrit.

2. 2

   Nouvel oeil

   Agence web et cybersécurité à Chambéry

   4,9/5 sur Google (18 avis, relevé du 3 octobre 2026) · Chambéry · 1 ou 2 salariés · créée en 2002

   Nouvel oeil, créée en 2002 à Chambéry et comptant 1 ou 2 salariés, dispose de 18 avis Google avec une note de 4,9 relevée le 2026-10-03.

   Son offre

   Son site publie des pages sur la cybersécurité des TPE et PME, le développement d’applications métier et le dépiratage WordPress.

   Pour qui

   Pour discuter d’un besoin mêlant application métier et sécurité, après présentation des corrections attendues.

   Points à vérifier

   Les éléments fournis ne documentent pas de correction d’API REST ; collaboration à distance à convenir depuis Chambéry.

3. 3

   IT Systèmes

   Entreprise informatique à Malakoff

   5,0/5 sur Sortlist (6 avis, relevé du 5 octobre 2026) · Malakoff · 44 personnes · créée en 2010

   IT Systèmes, créée en 2010 à Malakoff et comptant 44 personnes, affiche 6 avis Sortlist, une note de 5,0 et un budget minimal de 1 000 €, relevés le 2026-10-05.

   Son offre

   Son site présente des compétences en cybersécurité, développement, automatisation et modernisation. Une autre page traite des migrations informatiques vers le cloud.

   Pour qui

   Pour cadrer des corrections qui touchent à la fois l’application et son hébergement.

   Points à vérifier

   Le budget minimal publié ne décrit pas un chantier de correction REST ; collaboration à distance à convenir depuis Malakoff.

   Budget de départ

   à partir de 1 000 € (Sortlist)

4. 4

   EYANA

   Entreprise web et sécurité informatique à Sorgues

   4,69/5 sur Sortlist (1 avis, relevé du 5 octobre 2026) · Sorgues · 3 personnes · créée en 2026

   EYANA, créée en 2026 à Sorgues et comptant 3 personnes, affiche 1 avis Sortlist, une note de 4,69 et un budget minimal de 300 €, relevés le 2026-10-05.

   Son offre

   Son site présente la création de sites sur mesure et la sécurité informatique des infrastructures. Une publication porte sur les actions de cybersécurité pour les PME.

   Pour qui

   Pour vérifier l’adéquation entre un besoin de correction identifié et les compétences proposées.

   Points à vérifier

   Les faits ne présentent pas de référence consacrée aux API REST ; collaboration à distance à convenir depuis Sorgues.

   Budget de départ

   à partir de 300 € (Sortlist)

Le périmètre commence par les domaines, les accès et les données

Votre API REST fonctionne déjà et un client, un appel d’offres ou un audit technique exige un rapport. Le point de départ consiste à décrire ce que l’auditeur pourra réellement tester. Préparez les noms de domaine, les environnements accessibles, les routes documentées, les méthodes d’authentification et les rôles utilisateurs. Précisez qui exploite les serveurs et qui peut autoriser les essais. Un domaine connu du développeur ne suffit pas à délimiter les services exposés derrière une passerelle ou un hébergement partagé.

Les questions décisives portent sur les frontières de confiance. Une personne peut-elle consulter uniquement ses dossiers ? Une application cliente utilise-t-elle une clé commune à plusieurs organisations ? Les comptes techniques disposent-ils de droits différents des comptes humains ? Le périmètre comprend-il les fichiers téléchargés, les traitements différés et les interfaces d’administration ? Ces questions servent à préparer la consultation. Elles ne constituent pas des constats de vulnérabilité sur votre système.

Dans un exemple hypothétique, un éditeur RH expose une API sur un sous-domaine et confie les documents à un service de stockage distinct. Tester seulement les réponses de l’API laisserait ouverte la question des accès directs aux documents. Le cadrage devrait donc préciser les domaines concernés, les comptes nécessaires et les limites imposées par les services tiers. Toute extension du périmètre doit être autorisée avant les essais.

Le livrable de préparation peut rester simple : une description des actifs, une matrice des droits attendus et une liste des exclusions. Demandez aussi quelle version de l’application sera examinée. La recette de ce cadrage consiste à pouvoir associer chaque accès fourni à un usage prévu, chaque domaine à un responsable et chaque exclusion à une raison explicite. Vous obtenez alors une base commune pour comparer les propositions et comprendre ce que le futur rapport couvrira réellement.

Le choix du prestataire dépend du travail à réaliser

Le test d’intrusion recherche et documente des possibilités d’exploitation. La correction transforme ensuite le code, les droits ou la configuration. Pour cette page, les auditeurs sont présentés dans cet ordre éditorial : Scassi Conseil, Synacktiv, Adacis et OWN. Les correcteurs suivent dans un groupe distinct : Digital Unicorn, Nouvel oeil, IT Systèmes et EYANA. Aucun score calculé ne justifie cet ordre.

Les faits fournis placent les auditeurs au catalogue des services qualifiés PASSI de l’ANSSI, mis à jour le 15/09/2026. Leurs portées incluent les tests d’intrusion, le code source, l’architecture, la configuration et l’organisationnel, au niveau Élevé. Les périodes indiquées vont du 22/05/2026 au 22/05/2029 pour Scassi Conseil et Synacktiv, et du 20/04/2026 au 20/04/2029 pour Adacis et OWN. Ces éléments ne décrivent pas le contenu de votre future mission.

Digital Unicorn n’a aucune offre d’audit de sécurité ni de test d’intrusion dans les faits fournis. Son rôle concerne la correction et l’évolution du code. Pour les autres correcteurs, faites confirmer les compétences nécessaires au chantier identifié. Une page générale de cybersécurité ne démontre pas une pratique particulière des API REST. Demandez qui prendra en charge les modifications, qui les déploiera et qui vérifiera ensuite la disparition des chemins d’exploitation documentés dans le rapport.

Un pentest REST se prépare avec des comptes aux droits différents

Une proposition utile doit expliquer comment les essais couvriront les accès autorisés et les tentatives de franchissement des droits. Fournissez la documentation disponible, les parcours métier et des comptes représentatifs des rôles à examiner. Signalez les routes anciennes encore exposées et les interfaces réservées aux partenaires. Demandez comment seront traitées les différences entre la documentation et le comportement réel. Cette préparation aide à examiner les fonctions sensibles sans consacrer toute la mission à découvrir les usages ordinaires de l’application.

Le chemin technique doit suivre les données. Il peut partir de la connexion, continuer vers la lecture ou la modification d’un objet, puis examiner les exports et les opérations déclenchées en arrière-plan. Faites préciser la couverture des autorisations entre organisations, de la gestion des sessions et des clés applicatives. Pour la recherche « secure api key storage », traduisez le besoin en questions concrètes : où les clés sont-elles stockées, qui peut les lire, comment sont-elles révoquées et quelles traces permettent d’identifier leur utilisation ?

Dans un exemple hypothétique, une intégration avec un ERP transmet des commandes au moyen d’un compte technique. Le cadrage devrait décrire ses droits, les données accessibles et les conséquences d’une opération rejouée. Une recherche comme « api erp xl » ne permet pas, à elle seule, de connaître le produit ou les interfaces de votre projet. Fournissez leur désignation réelle et leur documentation avant de demander une couverture technique précise.

Le rapport attendu devrait relier les observations aux routes concernées, aux conditions d’accès et aux impacts métier. Demandez des éléments reproductibles suffisamment précis pour corriger, avec les informations sensibles masquées. La recette du livrable consiste à pouvoir transmettre chaque constat au responsable du code ou de l’exploitation sans refaire toute l’enquête. Les comptes, jetons et autorisations temporaires devront enfin être retirés selon une procédure convenue, en conservant les traces utiles à la compréhension des essais.

Les budgets observés ne donnent pas le prix de votre audit

Les montants disponibles sont des budgets affichés sur des annonces publiques de codeur.com : « 1 000 € à 10 000 € » et « Moins de 500 € ». Ils décrivent des intentions de projet, pas des devis de pentest, des transactions conclues ou des prestations équivalentes. Les faits ne permettent donc pas de déduire le prix de votre test d’intrusion API REST. Pour un éditeur RH devant fournir un rapport à un grand compte, le budget doit être demandé à partir du périmètre et des livrables attendus.

Comparez les propositions sur leur contenu. Faites distinguer la préparation des accès, les essais, la rédaction du rapport, la restitution et la vérification après correction. Demandez ce qui se passe lorsqu’une route prévue reste inaccessible ou lorsqu’une fonction sensible apparaît pendant les tests. Le devis devrait préciser le traitement de ces écarts. Un montant global devient difficile à comparer si les exclusions et les conditions de reprise ne sont pas écrites.

Les budgets de correction constituent un autre poste. Digital Unicorn publie un budget de départ « dès 8 000 € ». Les autres budgets de départ fournis sont de 1 000 € pour IT Systèmes et de 300 € pour EYANA. Ces données ne correspondent pas à un même périmètre de réparation et ne permettent pas de chiffrer une faille. Une modification du contrôle d’accès peut nécessiter une revue des parcours associés, des tests et une intervention sur le déploiement.

Préparez une demande qui sépare l’audit, les corrections et leur validation. Pour chaque poste, indiquez le résultat attendu, les accès disponibles et le responsable de réception. Demandez comment seront chiffrées les découvertes qui dépassent le périmètre initial. Vous pourrez ainsi arbitrer entre une couverture plus large et un examen centré sur les fonctions exigées par le client, en gardant les exclusions visibles dans le rapport final.

Le délai doit intégrer les accès, les corrections et la restitution

Aucune durée de pentest API REST n’est fournie dans les faits. Annoncer un nombre de jours pour une fintech ou un SaaS serait donc une estimation sans base dans ce dossier. Demandez un calendrier qui distingue la disponibilité de l’auditeur, la préparation, les essais, la remise du rapport et la validation des corrections. La date utile pour votre client est celle du livrable qu’il acceptera, avec son périmètre et ses réserves, pas seulement celle du démarrage des tests.

Avant de consulter, vérifiez les dépendances internes. Les comptes doivent fonctionner, les données de test être prêtes et les personnes responsables de l’hébergement joignables. Une autorisation portant sur le domaine principal peut laisser de côté un service externe ou un sous-domaine exploité autrement. Faites préciser les délais de fourniture des accès et le traitement des interruptions. Le calendrier proposé doit rendre visibles ces conditions pour éviter de confondre une attente administrative avec du temps consacré aux essais.

Dans un exemple hypothétique, un éditeur SaaS prépare un appel d’offres public et prévoit une mise à jour de son API pendant l’audit. Il faut convenir de la version examinée et du traitement des changements. Si le contrôle des droits évolue après les tests, le rapport devra permettre de comprendre quelle version a été observée. Cette décision appartient au cadrage ; elle ne permet pas de promettre une durée particulière ou une acceptation automatique par le destinataire.

Pour une fintech traitant des données de santé, prévoyez aussi la préparation d’un environnement représentatif et de données adaptées aux essais. Demandez quels écarts avec la production seront signalés. La recette du planning consiste à associer chaque étape à un responsable, à une condition de démarrage et à un livrable identifiable. Faites réserver un créneau pour discuter des constats et organiser la correction, afin que le rapport puisse réellement servir à débloquer la décision commerciale attendue.

Les essais doivent préserver les données et rester identifiables

Sur une API REST, les essais peuvent atteindre des opérations qui modifient un dossier, déclenchent un message ou lancent un traitement externe. Le cadrage doit donc identifier les actions sensibles et les effets à éviter. Demandez quelles manipulations seront autorisées, lesquelles nécessiteront un accord pendant la mission et lesquelles seront exclues. Faites distinguer les environnements et les domaines concernés. Une route accessible depuis une préproduction peut encore appeler un service utilisé en production.

Pour un cabinet comptable manipulant des données de santé, préparez des données adaptées et limitez les accès au périmètre utile. Demandez comment seront protégées les preuves intégrées au rapport, qui pourra les consulter et comment elles seront transmises. Le même raisonnement s’applique aux documents confidentiels d’un cabinet d’avocats. Ces précautions sont des conseils de préparation ; les faits fournis ne décrivent ni vos données réelles ni les protections déjà en place dans votre hébergement.

Un autre piège concerne la surveillance. Les équipes d’exploitation doivent pouvoir reconnaître les essais autorisés et distinguer un incident extérieur. Convenez des interlocuteurs, des plages d’intervention et d’un moyen d’interrompre les opérations. Prévoyez les informations nécessaires dans les journaux sans y ajouter de secrets. Si des limitations ou des protections sont temporairement adaptées pour les tests, documentez leur état initial et la procédure permettant de rétablir la configuration prévue.

La recette opérationnelle doit couvrir la sortie de mission autant que son démarrage. Vérifiez la révocation des jetons temporaires, la fermeture des comptes créés et la remise en état des accès modifiés. Demandez une liste des limites rencontrées : service indisponible, droits insuffisants ou fonction exclue. Une absence de constat sur une route non examinée ne doit pas être interprétée comme une validation. Cette traçabilité aide aussi à préparer une intervention ultérieure sans rouvrir des accès devenus inutiles.

Le secteur change les scénarios et les attentes du rapport

Les secteurs cités dans les faits ne justifient pas une durée ou un tarif propre à chacun. Ils aident surtout à choisir les scénarios métier à présenter à l’auditeur. Dans une fintech, décrivez les opérations sensibles et les intégrations qui peuvent les déclencher. Pour un logiciel RH, explicitez la séparation des organisations, les rôles administratifs et l’accès aux documents. Pour un éditeur SaaS, montrez comment les droits circulent entre l’interface web, les comptes techniques et les services hébergés.

Dans un cabinet d’avocats, un cabinet comptable ou une activité de courtage, le cadrage peut partir de la confidentialité des dossiers et des échanges avec les partenaires. En e-santé, précisez les données qui doivent être remplacées ou masquées dans l’environnement de test. Pour une plateforme de formation, décrivez les profils et les documents accessibles. En e-commerce, identifiez les opérations qui modifient une commande ou communiquent avec un prestataire externe. Ces exemples sont des pistes de cadrage, pas des vulnérabilités établies.

La raison de l’audit change aussi le livrable. Face à l’exigence d’un grand compte, demandez au destinataire le contenu attendu et les réserves acceptables avant de signer la mission. Pour un appel d’offres, reprenez les exigences documentaires du dossier. Avant une levée de fonds, faites préciser comment le rapport alimentera l’audit technique et le plan de correction. Aucun rapport ne peut être présenté ici comme automatiquement suffisant pour ces démarches, puisque leurs critères ne sont pas fournis.

Si votre consultation naît d’exigences de sécurité nouvelles, transmettez leur formulation exacte au prestataire sans lui attribuer d’avance une couverture particulière. Demandez quels éléments seront examinés et lesquels resteront hors mission. La recette consiste à pouvoir relier chaque attente métier à un scénario, puis à une preuve ou à une exclusion explicite. Cette correspondance permet au responsable technique et au décideur de lire le même rapport avec des attentes compatibles.

La correction se réceptionne sur le scénario qui a révélé la faille

Après le rapport, transformez les constats en travaux attribués. Pour chaque point, identifiez le composant concerné, le responsable du changement et les conditions nécessaires pour vérifier le résultat. Certaines actions relèveront du code, d’autres des comptes techniques, des secrets ou de la configuration d’hébergement. Demandez au correcteur de confirmer ce qu’il prend en charge et les accès dont il a besoin. Évitez de transmettre un rapport contenant des données sensibles à des intervenants qui n’en ont pas l’usage.

Digital Unicorn publie des éléments sur la modernisation Symfony, la maintenance et les migrations PHP après analyse du code. Nouvel oeil présente des applications métier et de la cybersécurité. IT Systèmes publie des compétences en modernisation et cloud. EYANA présente la sécurité des infrastructures et des sites sur mesure. Ces faits permettent d’ouvrir une discussion, mais ne prouvent pas la prise en charge d’une correction précise. Présentez les constats et demandez une réponse technique liée au code réellement utilisé.

Dans un exemple hypothétique, le rapport décrit un accès indu à un document appartenant à une autre organisation. La recette devrait reprendre ce scénario après modification, puis vérifier que l’accès légitime fonctionne toujours. Demandez aussi quels parcours voisins ont été examinés. Une réponse différente de l’API ne suffit pas à expliquer la correction si le document reste accessible autrement. Les preuves attendues doivent permettre de comprendre le changement sans diffuser les données utilisées pendant les essais.

Enfin, organisez la livraison dans votre exploitation : version déployée, configuration attendue, gestion des secrets et procédure de retour arrière. Faites préciser qui effectuera la vérification après correction et quelle trace sera remise au destinataire du rapport initial. Les constats encore ouverts doivent conserver un responsable et une décision explicite. Cette réception donne un état exploitable du projet : ce qui a changé, ce qui a été vérifié et les limites qui subsistent sur les domaines et services concernés.

Ce qu’il faut demander avant de signer

Questions fréquentes

Pour aller plus loin

• Accueil du comparateur
• Pentest entreprise
• Pentest ou bug bounty
• Prix pentest
• Corriger les failles d'une API REST
• Corriger les failles
• SSO et double authentification

Sources et méthode

• catalogue des produits et services qualifiés de l'ANSSI, mis à jour le 15/09/2026
• site de l'entreprise (https://www.scassi.com/en/)
• site de l'entreprise (https://www.synacktiv.com/)
• site de l'entreprise (https://www.adacis.net/)
• site de l'entreprise (https://www.own.security/en)
• fiche Sortlist (https://www.sortlist.fr/agency/digital-unicorn, relevée le 2026-10-03)
• pages publiées par l'agence
• fiche Google Maps (Google Maps « agence web Chambéry » (DataForSEO, 2026-10-02))
• registre Sirene (SIREN 442662169)
• site de l'agence (https://www.nouvel-oeil.com)
• données vérifiées pour anaska (relevé du 2026-10-03)
• site de l'agence (https://www.nouvel-oeil.com/)
• fiche Sortlist (https://www.sortlist.fr/agency/it-systemes, relevée le 2026-10-05)
• registre Sirene (SIREN 521984112)
• site de l'agence (https://www.itsystemes.fr/)
• fiche Sortlist (https://www.sortlist.fr/agency/eyana, relevée le 2026-10-05)
• site de l'agence (https://www.eyana.fr/)
• Prestataires retenus : site qui répond, spécialité présente sur une page de service de leur site, registre Sirene pour les entreprises françaises. Rédaction du 16 octobre 2026 ; dates de relevé des données précisées dans les fiches.