Snyk : prix, unité de facturation et alternatives
(guide d'achat)

Le 16 août 2026, la page tarifs de Snyk affichait quatre offres. Le 7 octobre, quand on l'a relevée à nouveau et archivée, il n'en restait que trois. L'offre intermédiaire Ignite avait disparu, et l'Enterprise ne se vendait plus au développeur mais en crédits, avec une grille de consommation publique. Entre-temps, la carte Team a cessé d'écrire que ses 25 $ s'entendaient par développeur. Une grille d'éditeur bouge, et elle bouge plus vite qu'un cycle d'achat.

Cette définition, c'est l'unité de facturation, et elle pèse plus lourd que le montant affiché : le Snyk prix publié est un prix unitaire, multiplié ensuite par un compteur que vous ne contrôlez pas directement. Snyk est un bon produit et je ne vais pas prétendre le contraire pour vendre autre chose ; reste à savoir ce qu'on achète, ce que le tri des résultats coûtera une fois la signature séchée, et quelles alternatives à Snyk tiennent la route selon le besoin.

Snyk, c'est d'abord du SCA

On range souvent Snyk dans la case "SAST" par raccourci, alors que son histoire est ailleurs. L'outil est né sur l'analyse des dépendances open source, ce qu'on appelle le SCA (Software Composition Analysis) : il lit votre package-lock.json, votre pom.xml ou votre go.sum, reconstruit l'arbre complet des bibliothèques embarquées, et confronte cette liste à une base de vulnérabilités connues. C'est le cœur historique du produit, et c'est encore ce qu'il fait le mieux.

Le reste s'est ajouté par couches. Snyk Code apporte le SAST, après le rachat de DeepCode ; Snyk Container scanne les images et leurs paquets système ; Snyk IaC inspecte Terraform, Kubernetes et consorts. Chacun de ces produits a ses propres limites de tests, ce qui compte pour la suite. Si la carte des familles d'outils n'est pas nette dans votre tête, le pilier SAST, DAST, IAST et ce que l'IA change remet chaque catégorie à sa place avant qu'on parle argent.

Ce marché existe parce qu'une application moderne embarque rarement moins de plusieurs centaines de paquets, dont la quasi-totalité arrive indirectement, et que ce périmètre est devenu une cible en soi. C'est le sujet de l'attaque sur la chaîne d'approvisionnement logicielle, et c'est aussi ce qui a rendu le SBOM obligatoire dans un nombre croissant de contrats. Un outil de SCA, c'est d'abord un inventaire qui se met à jour tout seul.

Le prix de Snyk au 7 octobre 2026 : trois offres, dont une en crédits

On a relevé la page tarifaire officielle de Snyk le 7 octobre 2026, en HTML brut et après exécution du JavaScript, sans compte ni formulaire, dans le cadre d'un relevé des prix publics de douze éditeurs AppSec. Je reprends les montants tels que publiés, en dollars, avec leur formulation d'origine :

• Free : "$0 / month". 5 projets et 100 tests Snyk Code par mois d'après le tableau comparatif de la page. Utilisable, plafonné, et suffisant pour évaluer sérieusement l'outil.
• Team : "For development teams of up to 10 developers", "Starting at $25 / month", "billed monthly". 100 projets et 1 000 tests Code par mois. La carte ne dit pas si les 25 $ sont par développeur ou pour l'équipe, alors que la FAQ de la même page continue d'expliquer comment Snyk compte les développeurs. On ne peut donc pas calculer la facture d'une équipe de huit à partir de la page.
• Enterprise (Platform Subscription) : "Contact Sales for pricing", mais avec une grille de consommation publiée. On achète des crédits à l'avance, 1 crédit = 1 $, puis chaque produit puise dans le solde : Snyk Code et Snyk Open Source à 1 crédit par contributeur actif et par jour, Secrets à 0,66, IaC à 0,33, Container à 0,33 par image surveillée et par jour. La consommation au-delà du solde est facturée après coup.

Ce qui a disparu compte autant : l'offre Ignite, affichée le 16 août à partir de 1 260 $ par an et par développeur contributeur, n'apparaît plus nulle part sur la page. Et la grille de crédits permet un calcul que l'ancien "sur devis" interdisait : SAST plus SCA, c'est 2 crédits, donc 2 $, par contributeur actif et par jour au tarif de la grille, avant toute remise négociée. Reste à savoir combien de contributeurs sont actifs chaque jour, ce que la page ne définit pas. Le montant du contrat, lui, reste sur devis, et c'est ce qui range Snyk parmi les éditeurs dont la facture ne se calcule pas depuis la page.

Le compteur qui décide de la facture

L'unité de référence reste le contributing developer, que la FAQ de la page tarifs définit toujours, et dont la définition publiée tient en une ligne : "developers who have made a commit to a private repo monitored by Snyk in the last 90 days". Traduit en langage de facture : tout compte git ayant poussé un commit sur un dépôt privé surveillé pendant les quatre-vingt-dix derniers jours entre dans le décompte. Le prestataire venu deux semaines en renfort, le développeur d'une autre équipe qui corrige une typo dans un README, le compte de service qui pousse des commits de release : personne ne les a provisionnés, et le compteur monte quand même. La mécanique est légitime, elle est même plutôt équitable sur le principe, mais elle a des effets de bord que peu d'équipes anticipent avant la première facture.

Le second compteur, moins visible, est celui des tests mensuels. Chaque produit a son propre plafond, et ces plafonds se consomment vite dans une CI où chaque pull request déclenche une analyse. La page tarifs ne chiffre que les projets et les tests Code ; les autres plafonds de l'offre gratuite viennent de la documentation, relevée le 16 août 2026 :

Ce que je lis dans ce tableau : cent tests de code par mois en gratuit, c'est environ cinq pull requests par jour ouvré sur un seul dépôt actif. Une équipe de six personnes atteint ce plafond avant la fin de la deuxième semaine. Le palier gratuit sert donc de période d'essai, et c'est une stratégie commerciale assumée. Autant le savoir en montant le dossier plutôt qu'en le découvrant à la première alerte de quota.

La base de vulnérabilités, l'actif que vous payez vraiment

Un scanner de dépendances vaut ce que vaut sa base. Le moteur qui parcourt un arbre de dépendances est, techniquement, la partie facile ; la partie coûteuse, c'est de maintenir un référentiel à jour, dédoublonné et enrichi. C'est là que Snyk place son argument principal.

Sur sa page dédiée, l'éditeur revendique une base qui couvre "3x more vulnerabilities than the next largest public database", annonce que "92% of JavaScript vulnerabilities were reported by Snyk before the NVD", et affiche un gain moyen de "47 days" sur la détection. Ces chiffres viennent de l'éditeur et je les cite comme tels : ils ne sont pas vérifiables depuis l'extérieur, et Snyk ne figure pas dans notre banc, je n'ai donc rien à leur opposer directement. Ce que j'ai mesuré, c'est l'autre terme de la comparaison, les scanners gratuits.

Ce qui est en revanche public et documenté, c'est le contexte qui donne du poids à ce type d'argument. Le NIST a annoncé en avril 2026 un modèle de triage priorisé pour la NVD, en reconnaissant que l'enrichissement complet de chaque CVE n'est plus un objectif atteignable avec ses moyens. Une partie des vulnérabilités publiées reste donc sans métadonnées exploitables pendant longtemps. Une base commerciale curée manuellement, ou les avis GitHub et la base OSV côté ouvert, ne sont plus un supplément de confort. Le point de comparaison honnête n'est pas "Snyk contre la NVD", c'est "Snyk contre la combinaison OSV plus GHSA", qui est gratuite et loin d'être ridicule.

Trois scanners gratuits mesurés : d'accord sur le code, pas sur l'OS

Pour savoir ce que vaut "la combinaison gratuite", on a fait tourner les trois scanners libres que l'on cite le plus souvent comme alternatives à Snyk sur quatre images Docker publiques, figées par digest le 7 octobre 2026 : grype 0.120.1, trivy 0.75.0 et osv-scanner 2.6.0, bases téléchargées le jour même, mises à jour coupées au moment du scan, configuration par défaut, sans aucun filtre de gravité ni de statut de correctif. Les cibles sont une image de base debian:10, en fin de support depuis juin 2024, et trois applications volontairement vulnérables de l'OWASP : PyGoat (Python), Juice Shop (Node.js) et WebGoat (Java, sur Ubuntu 24.04). On compte les CVE distinctes, à partir des alias CVE que chaque outil fournit lui-même. Snyk n'est pas dans ce banc.

Deux mondes cohabitent dans ce graphique. Sur Juice Shop, les trois disent presque la même chose : 153 CVE communes sur 157. Et quand on isole les dépendances applicatives de chaque image, l'accord tient partout : 143 CVE communes sur 149 pour les paquets PyPI de PyGoat, 103 sur 107 pour les paquets npm de Juice Shop, 50 sur 54 pour les archives Maven de WebGoat. Ces taux résistent à la façon de regrouper les identifiants : en fusionnant les CVE et les avis qui leur sont reliés dans une même sortie, on obtient 96,8, 96,3 et 92,7 %.

Sur les paquets système anciens, en revanche, l'accord s'effondre. Sur debian:10, grype remonte 80 CVE, trivy 38 et osv-scanner 4 : le choix de l'outil change le chiffre d'un facteur 20. Ce n'est pas un bug d'osv-scanner : la base OSV ne publie plus pour Debian 10 que des avis de correctif (DLA, DSA) et quelques CVE, et le scan en ligne donne le même résultat. Sur les paquets Debian de PyGoat, 366 CVE seulement sont communes aux trois sur 1 359. Une partie de l'écart tient à une politique : grype et trivy remontent aussi les vulnérabilités "non corrigées" ou que la distribution ne corrigera pas, que d'autres outils omettent par conception.

Dernier piège, le plus sournois. Sur WebGoat, osv-scanner en mode hors ligne n'a trouvé aucune vulnérabilité dans les 117 paquets Ubuntu ; relancé en ligne, il en trouve 161. La base hors ligne nomme l'écosystème "Ubuntu:24.04:LTS" quand l'inventaire déclare "Ubuntu:24.04", et rien ne correspond. Aucun message d'erreur : juste un zéro, qui ressemble à une image propre.

Pour un acheteur, la lecture est utile. Sur les dépendances applicatives, la combinaison gratuite s'accorde avec elle-même à plus de 92 % : un éditeur qui vend sa base devra montrer sa différence ailleurs. Sur les paquets système d'une distribution ancienne, les outils divergent d'un facteur 20, et c'est là qu'une démonstration commerciale se juge. Demandez à voir le scan d'une vieille image de base de votre parc, et comparez-le aux trois outils libres sur la même image, le même jour.

Le coût caché : le bruit sur les dépendances transitives

Voilà la ligne de dépense qu'aucun devis ne mentionne. Sur le même banc, on a passé npm audit sur le lockfile de Juice Shop v20.2.0 : 1 329 paquets, dont 62 déclarés vulnérables (55 si l'on écarte les dépendances de développement). 23 sont des dépendances directes, 39 arrivent par transitivité, et 25 des 62 n'ont aucun avis propre : ils sont marqués parce qu'ils embarquent un paquet vulnérable. Pour 42 d'entre eux, le correctif proposé par npm passe par une version majeure, donc par un changement d'API possible. Combien de ces failles sont atteignables depuis les points d'entrée de l'application, le banc ne le dit pas : c'est précisément le travail de tri qui reste à faire.

Le travail de tri qui suit se paie en heures d'ingénieur, mois après mois, et ces heures dépassent souvent le montant de la licence. Pire, le tri finit par s'arrêter : quand un tableau de bord affiche en permanence des dizaines d'alertes rouges dont on sait par expérience que l'essentiel est sans conséquence, plus personne ne le regarde. C'est le mécanisme classique de la fatigue d'alerte, celui qu'on décortique dans la gestion des vulnérabilités, et il annule la valeur de l'outil bien plus sûrement qu'un défaut de couverture.

La réponse technique à ce problème est l'analyse d'atteignabilité. Elle consiste à construire le graphe d'appels de votre application et à vérifier si la fonction vulnérable est réellement joignable depuis une entrée. Snyk propose cette analyse, avec une couverture de langages limitée ; sur les écosystèmes non couverts, l'outil retombe sur un score de risque composite qui mêle sévérité CVSS, probabilité EPSS et maturité d'exploitation. C'est mieux que rien, et ce n'est pas la même chose que de savoir si le code est appelé. Vérifiez précisément quels langages de votre parc bénéficient de l'atteignabilité avant de valoriser cette fonctionnalité dans votre comparatif.

Les alternatives à Snyk, par cas d'usage

Un remplaçant global n'existe pas, puisque Snyk facture quatre produits sur une même ligne. Avant de comparer quoi que ce soit, il faut donc retrouver lequel des quatre a réellement motivé l'abonnement. La réponse tient souvent en un seul produit, et le reste de la facture couvrait des moteurs allumés par défaut.

Ce que publient les autres éditeurs

Le même jour, on a relevé les pages tarifs de onze autres outils AppSec, dont notre SecAI. Sur les onze concurrents relevés, Snyk compris et own2pwn exclu, cinq publient un prix qui permet de calculer une facture : SonarQube Cloud, Semgrep, Aikido, Socket et GitHub. Snyk n'en fait pas partie, faute d'unité écrite sur la carte Team et de montant de contrat pour l'Enterprise.

Avec ces grilles publiques, on peut calculer ce que coûte une équipe. On a pris, pour 5, 10 et 15 personnes, le palier public le moins cher qui couvre à la fois le SAST et le SCA, en ignorant les quotas de dépôts et de scans. Snyk n'y figure pas, puisque la page ne permet pas le calcul, ni SonarQube (facturé à la ligne de code), ni les offres sur devis. SecAI, notre produit, n'y figure pas non plus : c'est un forfait, 99 ou 299 € par mois, dont les quotas ne s'expriment pas dans la même unité.

La lecture n'est pas "Semgrep est gratuit" : son offre gratuite s'arrête à 10 contributeurs et 10 dépôts, et la marche suivante coûte 805 € par mois à 15 personnes. Les grilles par personne pénalisent la croissance de l'équipe, les forfaits pénalisent les petites équipes qui ne remplissent pas le palier. Les quotas ignorés ici (dépôts, scans, crédits d'IA) peuvent renverser le classement : faites le calcul avec les vôtres.

Vous voulez juste du SCA gratuit : Dependabot et OSV-Scanner

Si votre code vit sur GitHub, Dependabot est déjà là, activable en deux clics, sans ligne supplémentaire au budget. Il alerte sur les dépendances vulnérables et ouvre les pull requests de mise à jour. Pour travailler hors GitHub ou en ligne de commande, OSV-Scanner interroge la base OSV sur la plupart des écosystèmes et s'intègre sans douleur dans un pipeline. Deux autres outils libres méritent le détour, et on les a fait tourner sur des projets de démonstration Node et Java, puis sur WebGoat : OWASP Dependency-Check et npm audit testés. Ce que vous perdez par rapport à une offre commerciale : la gouvernance multi-équipes, les tableaux de bord consolidés, l'atteignabilité et un interlocuteur au téléphone. Pour une structure de moins de vingt développeurs, ce n'est parfois pas grand-chose.

Vos conteneurs : Trivy et Grype

Trivy est devenu le réflexe par défaut sur le scan d'images : paquets système, dépendances applicatives, mauvaises configurations et secrets, le tout en une commande et sans licence. Grype joue dans la même catégorie, et se marie bien avec Syft pour produire un SBOM exploitable. Le banc ci-dessus donne leur vrai profil : d'accord entre eux sur les dépendances applicatives, et du simple au double sur une Debian 10 en fin de vie (80 CVE pour grype, 38 pour trivy). Sur ce périmètre, le gratuit suffit largement, à condition de choisir un outil et de s'y tenir ; tout se joue ensuite sur qui traite les résultats, et à quel rythme.

Votre besoin est le SAST : Semgrep

Semgrep attire les équipes qui veulent écrire et auditer leurs propres règles, avec une syntaxe qui ressemble au code inspecté et un moteur ouvert qui tourne en local. Le modèle commercial est lui aussi orienté par contributeur (30 $ par mois pour le SAST au 7 octobre 2026, autant pour le SCA, 15 $ pour les secrets), si bien que l'arbitrage se joue sur la philosophie bien plus que sur le prix unitaire : transparence et contrôle des règles d'un côté, suite unifiée clé en main de l'autre. Si la comparaison vous emmène plus haut, vers le segment entreprise où le prix cesse complètement d'être affiché, le guide d'achat Checkmarx prend le relais. Dans tous les cas, le vrai travail est le câblage dans la chaîne de build, sujet traité en détail dans intégrer SAST et DAST dans sa CI/CD.

Snyk vs SonarQube : la comparaison qui revient toujours

C'est la confrontation la plus fréquente en comité d'achat, et elle repose souvent sur un malentendu, parce que les deux produits ne répondent pas à la même question initiale. SonarQube vient de la qualité de code et de la dette technique, avec la sécurité greffée par-dessus et principalement réservée à ses éditions payantes. Snyk vient des dépendances, avec le code ajouté ensuite. Si votre douleur est la maintenabilité et le blocage des régressions en pull request, l'un est plus proche du besoin ; si c'est la chaîne d'approvisionnement et les images de conteneurs, c'est l'autre. Le détail des éditions, des limites de la Community et du modèle de facturation à la ligne de code est dans SonarQube : prix, limites et alternatives. Beaucoup d'organisations finissent avec les deux, ce qui se défend, à condition d'avoir compté le coût de tri cumulé et pas seulement les deux licences.

Vous jugez sur l'atteignabilité

Une catégorie d'outils a fait de l'analyse d'atteignabilité son argument central plutôt qu'une fonctionnalité parmi d'autres, avec des couvertures de langages plus larges et des annonces de réduction de bruit spectaculaires. Prenez ces pourcentages pour ce qu'ils sont, du marketing chiffré par le vendeur, et demandez systématiquement un essai sur votre dépôt le plus laid. C'est le seul protocole qui vaut quelque chose : le nombre d'alertes avant, le nombre après, et surtout le nombre de tickets réellement ouverts et fermés dans les trente jours qui suivent.

La position d'own2pwn, sans enjoliver

own2pwn développe un SCA augmenté par l'IA qui attaque le problème de tri décrit juste au-dessus : hiérarchiser par atteignabilité réelle plutôt que par sévérité déclarée. Il est disponible en self-service. Le comparer fonctionnalité par fonctionnalité à un produit installé chez des milliers d'équipes aurait peu de sens, et brandir un taux de réduction du bruit non mesuré en aurait encore moins. Le seul verdict qui compte se prend sur votre dépôt : le nombre d'alertes avant, le nombre après, et le nombre de tickets réellement fermés.

Ce qui tourne en production, c'est la plateforme de gestion de la surface d'attaque externe. Elle regarde ce que votre organisation laisse joignable sur Internet, pas ce que contient votre code : autre terrain, autre question, et la placer face à Snyk n'aurait pas de sens.

Reste enfin ce qu'aucun scanner de cette page ne trouvera, quel que soit son prix : le contrôle d'accès incohérent d'un endpoint à l'autre, la logique métier détournable, la race condition sur un flux de paiement. Ces failles n'ont pas de signature dans une base de CVE parce qu'elles sont propres à votre application. Elles se trouvent en lisant le code et en l'attaquant, ce qui est le travail d'un pentest whitebox.

À retenir

• L'unité de facturation prime sur le prix affiché. Snyk compte les développeurs contributeurs, définis comme ceux ayant poussé un commit sur un dépôt privé surveillé dans les 90 derniers jours. Ce compteur suit l'activité git, pas vos décisions d'administration.
• Les tarifs publics au 7 octobre 2026 : Free à 0 dollar, Team "starting at $25 / month" pour 10 développeurs au plus, sans unité écrite sur la carte, et Enterprise en crédits (1 crédit = 1 dollar, 1 crédit par contributeur actif et par jour pour le SAST, autant pour le SCA), contrat sur devis. L'offre Ignite, affichée en août, a disparu.
• L'offre gratuite est plafonnée en tests, pas seulement en projets : 200 tests Open Source, 100 tests Code, 100 tests Container et 300 tests IaC par mois. C'est un excellent moyen d'évaluer, pas un mode d'exploitation durable.
• Le coût réel se cache dans le tri. Le bruit sur les dépendances transitives non atteignables se paie en heures d'ingénieur tous les mois, et finit par tuer l'usage de l'outil. Vérifiez quels langages de votre parc bénéficient de l'analyse d'atteignabilité.
• Les scanners gratuits s'accordent sur le code, pas sur l'OS : 92,6 à 96,3 % des CVE applicatives vues par grype, trivy et osv-scanner à la fois sur notre banc, mais 80, 38 et 4 CVE sur la même image debian:10. Un zéro peut aussi venir d'un nom d'écosystème qui ne correspond pas.
• Les alternatives se choisissent par cas d'usage : Dependabot et OSV-Scanner pour le SCA gratuit, Trivy et Grype pour les conteneurs, Semgrep pour le SAST à règles ouvertes, SonarQube si le besoin dominant reste la qualité de code.
• Aucun de ces outils ne remplace un test d'intrusion : ils comparent votre code à des motifs et à des bases connues, ils ne comprennent pas l'intention de votre application.

Un outil de SCA se juge au renouvellement : douze mois plus tard, combien d'alertes ont été réellement fermées pour le montant payé, et par combien de personnes. Ce ratio-là ne figure sur aucune page tarifaire, et c'est pourtant le seul chiffre qui décide de reconduire ou pas. S'il est mauvais chez vous, le SCA augmenté par l'IA d'own2pwn vise ce point précis, en self-service ; on en parle par la page contact.

Questions fréquentes sur les prix Snyk