Si cela vaut la peine de construire, cela vaut la peine de sécuriser.

Le codage vibratoire a fait couler beaucoup d'encre. Si l'automatisation et le codage avec l'IA ne sont pas nouveaux, le vibe coding promet de démocratiser le développement de logiciels : il suffit de décrire ce que l'on veut en langage naturel et de laisser le LLM faire le reste. 

Des IDE améliorés par l'IA comme Cursor, Copilot dans VS Code, et Windsurf, aux plateformes qui font abstraction totale du codage (comme Bolt, Lovable, et v0), il y a déjà eu une explosion des outils dans ce domaine, et nous nous attendons à ce que la croissance exponentielle se poursuive.

Consultez AINativeDev pour une vue d'ensemble du paysage du développement de l'IA  

Nous ne voulons que des bonnes vibrations

Il est rassurant de pouvoir construire rapidement et "d'oublier que le code existe" - surtout si vous n'êtes pas un développeur professionnel - mais le plus grand risque avec le codage vibratoire est de ne pas savoir ce que l'on ne sait pas, et la plupart du temps, on ne comprend pas ce que fait le code généré par l'IA. 

Bien sûr, vous pouvez valider qu'il fait ce que vous attendez de lui, mais sans savoir ce qui se passe sous le capot, vous ne saurez pas toujours quels risques le code crée jusqu'à ce qu'il soit trop tard (et le débogage est notoirement plus difficile que l'écriture du code en premier lieu). Si vous faites l'effort de construire quelque chose - même si vous accélérez ce processus grâce au codage vibratoire - la dernière chose que vous souhaitez est d'être retardé par des incidents de sécurité.

Même les développeurs chevronnés ont des zones d'ombre en matière de sécurité, et si le vibecodage rend le développement de logiciels plus accessible, il rend aussi plus rapide et plus facile de laisser votre application exposée à des vulnérabilités et à des attaques, comme les injections SQL, les attaques par traversée de chemin et les secrets vulnérables aux mauvais acteurs. Bien que certaines plateformes de vibe coding s'efforcent de rester à l'affût des vulnérabilités(v0 est par défaut sceptique à l'égard du code LLM), il existe toujours un risque réel de failles de sécurité lors du vibe coding, ce qui adonné lieu à l'observation sarcastique suivante : vibe coding = Vulnérabilité en tant que service. 

Prenons l'exemple ci-dessous :

‍

Malheureusement, il n'y a pas de raison évidente pour laquelle notre malheureux ami ci-dessus a dû fermer son application et repartir à zéro. Il est clair que ses clés API ont été divulguées, ce qui a permis à des pirates d'usurper son identité, c'est-à-dire d'accéder à des données, des fonctionnalités ou des ressources, ou de les modifier.

Un certain nombre de problèmes de gestion des clés d'API non sécurisées auraient pu être à l'origine de cette situation : codage en dur des secrets dans son application, fichier de variables d'environnement téléchargé à son insu sur son serveur ou vulnérabilité de traversée de chemin ( cela est même arrivé à Atlassian). En l'absence de contrôles et de processus de sécurité supplémentaires, il aurait été facile pour un pirate ou un robot d'accéder à ses clés API. 

Vulnérabilités et risques courants en matière de sécurité

Que vous soyez seul avec ChatGPT ou que vous codiez à l'aide d'un outil spécialisé comme Lovable, vous êtes vulnérable à ces types courants de cyberattaques. 

Scripts intersites (XSS)

Une attaque de type cross-site scripting (XSS) exploite les vulnérabilités des applications web dans lesquelles les données fournies par l'utilisateur ne sont pas correctement validées ou assainies avant d'être affichées ou traitées. Les pirates peuvent alors "injecter" un code malveillant par l'intermédiaire de l'entrée utilisateur, et lorsque le script injecté est exécuté, il peut accéder à des informations sensibles ou effectuer des actions non autorisées pour le compte de la victime (dans ce cas, l'un de vos utilisateurs). Les attaques XSS peuvent être un amusement inoffensif (comme dans ce tweet auto-retweeté), mais elles exposent vos utilisateurs au risque de voir leurs données exposées ou même leurs comptes pris en charge par des pirates informatiques. 

Attaques par injection SQL

Comme XSS, une attaque par injection SQL (SQLi) injecte un code malveillant dans une application, souvent par l'intermédiaire d'un champ de saisie utilisateur vulnérable. Comme SQL est le langage utilisé par de nombreuses applications pour interroger leur base de données sous-jacente, ce type d'attaque permet aux pirates de visualiser ou de modifier votre base de données - d'accéder à des données confidentielles ou même de supprimer des enregistrements. La violation de données d'Equifax en 2017 était le résultat d'une attaque par injection SQL, Equifax elle-même n'était pas visée - l'entreprise avait omis d'appliquer un correctif de sécurité à l'une de ses dépendances.  

Attaques par traversée de chemin

Les attaquants peuvent manipuler les entrées de chemin de fichier (généralement des URL ou des paramètres de fichier) pour inciter votre application à renvoyer des fichiers ou des répertoires non publics, en contournant les contrôles d'accès et en leur permettant de lire et d'écrire dans des fichiers contenant des données confidentielles. Ce type d'attaque est également rendu possible par des entrées utilisateur non sécurisées. En 2010, des chercheurs ont découvert une vulnérabilité de traversée de chemin dans l'application Confluence d'Atlassian qui aurait permis aux attaquants de récupérer n'importe quel fichier sur le serveur qui exécute Confluence, sur la base des autorisations de l'utilisateur sous lequel Confluence est exécuté.

Fuite de secrets

Les secrets - tels que les mots de passe, les clés de chiffrement, les jetons d'API et les certificats numériques - donnent à des acteurs malveillants les clés de votre royaume. Ces données sensibles peuvent permettre à des pirates d'usurper votre identité, d'accéder à vos données et de modifier votre code. Selon le rapport GitGuardian State of Secrets Sprawl, 23 millions de secrets ont été découverts dans des référentiels de code source publics en 2024 (soit une augmentation de 25 % par rapport à l'année précédente). Les secrets peuvent être exposés en les codant accidentellement en dur dans votre application, ou par le biais d'une vulnérabilité comme la compromission tj-actions/changed-files de mars 2025 : les attaquants ont modifié le code de l'action GitHub tj-actions/changed-files, ce qui a amené l'action compromise à imprimer des secrets CI/CD dans les journaux de construction des actions GitHub.

Attaques contre la chaîne d'approvisionnement

Jusqu'à 85-95% du code de votre application pourrait être alimenté par des bibliothèques et des projets open-source. Les attaques de la chaîne d'approvisionnement n'exploitent pas un type spécifique de vulnérabilité ou ne ciblent pas une application particulière, mais s'attaquent plutôt aux projets open-source sous-jacents dont dépendent de nombreuses entreprises. La violation de données d'Equifax mentionnée ci-dessus était le résultat d'une attaque de la chaîne d'approvisionnement qui avait déjà été atténuée, ce qui montre l'importance de surveiller vos dépendances et d'appliquer rapidement les correctifs de sécurité. 

Le vibrocodage est un outil formidable pour l'exploration et l'élaboration d'une validation de principe, mais dès que vous souhaitez transformer quelque chose en produit viable et en entreprise, vous devez mettre en place des contrôles de sécurité et des bonnes pratiques pour protéger ce que vous avez construit. 

Ne puis-je pas simplement demander à l'IA d'écrire un code plus sûr ?

Il s'agit d'une question valable. Nous savons que l'IA n'écrit pas de code sécurisé par défaut, mais une amélioration rapide et concrète consiste à lui demander explicitement de le sécuriser (en ajoutant littéralement les mots "et de le sécuriser" à votre invite). Il est surprenant de constater que cela permet d'obtenir un code présentant moins de vulnérabilités.

Vous pouvez également demander à l'IA d'examiner son propre code à la recherche de vulnérabilités et de lacunes de sécurité, par exemple en lui demandant de trouver des secrets codés en dur, de vérifier que les données ne sont pas accessibles au public, d'analyser le projet à la recherche de dépendances vulnérables ou d'identifier les champs de saisie de l'utilisateur (tels que les formulaires) dont la validation des entrées est insuffisante. Tous ces efforts amélioreront la sécurité de votre application.

Mais l'intérêt de vérifier que le code généré par l'IA ne contient pas d'hallucinations, de vulnérabilités ou d'autres failles de sécurité potentielles, c'est qu'il est trop risqué de le laisser s'auto-corriger sans surveillance humaine. Il est tout à fait possible d'intégrer l'IA aux méthodes d'analyse traditionnelles pour les améliorer, mais pas pour les remplacer (par exemple, Aikido utilise l'IA pour trier automatiquement les alertes de sécurité et proposer des correctifs).

Les ingénieurs logiciels les plus compétents sont aussi généralement ceux qui sont les plus à l'aise pour admettre qu'ils ne savent pas quelque chose. Le problème, lorsqu'on s'appuie trop sur l'IA pour s'auto-contrôler, est qu'il n'est pas rare qu'elle affirme avec assurance que quelque chose est faux, au lieu d'admettre son incertitude. C'est pourquoi nous ne recommandons pas de compter uniquement sur l'IA pour sécuriser votre application.

La bonne nouvelle, c'est que de nombreuses entreprises et projets open-source se sont consacrés à la résolution de ces problèmes de sécurité bien avant que le codage vibratoire ne devienne une pratique courante. L'une des plus grandes leçons que les nouveaux développeurs apprennent est de se tenir sur les épaules des géants. Il y aura de nombreux composants de votre application qui seront sensibles et critiques (des choses comme l'authentification, la cryptographie, ou même simplement la façon dont vous laissez les utilisateurs télécharger des fichiers dans votre interface utilisateur), et demander à Cursor ou GPT de les construire pour vous est.. : 

1. Ne va pas contribuer à la différenciation de votre produit
2. Forte probabilité d'introduire des risques de sécurité

Il est de loin préférable, dans ces cas-là, de s'appuyer sur des fournisseurs qui se concentrent exclusivement sur les solutions à ces problèmes. Les LLM ne sont pas spécifiquement formés aux meilleures pratiques ou à la résolution d'un problème de la manière la plus efficace ou la plus sûre. Dans de nombreux cas, la solution la plus élégante consiste à utiliser un service préexistant plutôt que de créer son propre service (même si l'on confie le gros du travail à l'IA).

Il est facile de se sentir dépassé et de ne pas savoir par où commencer. Nous avons établi cette liste de contrôle pour vous aider à commencer à construire de manière plus sûre. 

‍

Niveau 0

Il s'agit des mesures de sécurité de base que vous devez mettre en place dès que possible. Une fois que ces pratiques sont mises en place et font partie de votre processus, vous pouvez construire librement sans tuer l'ambiance.

Mettre en œuvre les meilleures pratiques Git

L'un des pièges courants du codage vibratoire est que, lorsqu'on ajoute une nouvelle fonctionnalité ou qu'on tente de résoudre un problème, il est plus intuitif de remplacer simplement ce que l'on avait auparavant par le nouveau code généré par l'IA. Cela fonctionne jusqu'à ce que ce ne soit plus le cas ; finalement, vous risquez de vous heurter à un mur où rien de ce que produit l'IA n'est utile et où vous vous retrouvez encore plus mal en point qu'avant.

C'est à cela que sert le contrôle de version

Le contrôle de version tel que Git est apparu comme un moyen pour les développeurs de collaborer sur des projets sans écraser le travail des autres. Mais même si vous construisez en solo, Git sert à sauvegarder vos progrès, ce qui permet d'isoler les bogues et de revenir sur une modification lorsque quelque chose ne va pas. Voici trois pratiques Git clés qui vous aideront à construire en toute sécurité :

Créer un fichier .gitignore pour les fichiers sensibles

Un fichier .gitignore est simplement un fichier texte qui indique à Git ce qu'il doit ignorer (c'est-à-dire ne pas livrer dans votre dépôt). Typiquement, vous voulez que Git ignore les fichiers générés par l'ordinateur comme les logs, car ils encombrent votre dépôt et peuvent contenir des informations sur l'application qui pourraient être utilisées pour la compromettre. Votre fichier .env doit également être ignoré, car il contient des variables d'environnement sensibles (comme des clés API et des mots de passe) que les pirates pourraient utiliser pour se faire passer pour vous et accéder à votre système. 

Maintenir un historique clair des livraisons

En gardant les modifications aussi autonomes que possible, il est plus facile d'identifier le moment où un bogue ou une vulnérabilité a été introduit, et plus facile de revenir en arrière sans avoir à refaire d'autres travaux. Aller plus loin et mettre en place des commits signés permet de vérifier que les bons développeurs commettent du code dans votre dépôt (même s'il ne s'agit que de vous !). 

Séparer les branches de développement, de mise à l'essai et de production des fonctionnalités

Les branches dans Git permettent de créer des espaces distincts et autonomes pour travailler sur le code, le prévisualiser et le publier. Le développement actif de nouvelles fonctionnalités dans une branche séparée permet d'éviter qu'un code inachevé, bogué ou non sécurisé ne soit accidentellement transféré dans votre application. Une fois qu'une nouvelle fonctionnalité est entièrement développée et testée, une branche de mise à l'essai agit comme une autre barrière de sécurité et de qualité, vous permettant de réviser et de finaliser les changements avant de les mettre en production. Seules les fonctionnalités entièrement testées et stables peuvent alors être intégrées dans la branche de production (généralement appelée branche principale).

Dépôts Git hébergés : GitHub GitLab   

Séparer les secrets du code

‍

‍

Les secrets - tels que les mots de passe, les clés de chiffrement, les jetons d'API et les certificats numériques - doivent être traités séparément du code afin d'éviter de s'engager directement dans votre base de code. Vous pouvez vérifier votre code pour les secrets avec Aikido, même à partir de votre IDE Cursor.

Protégez votre application contre les attaques DDoS

Une attaque par déni de service distribué (DDoS) tente de perturber le trafic normal d'un serveur, d'un service ou d'un réseau ciblé en submergeant la cible ou son infrastructure environnante par un pic de trafic Internet. Ces attaques peuvent avoir des conséquences dévastatrices, et il est étonnamment simple de se protéger en intégrant des protections DDoS de base à un réseau de diffusion de contenu (CDN) tel que CloudFlare ou CloudFront. Certains hébergeurs de domaines proposent même un CDN en tant que service intégré. 

Ne pas faire l'authentification tout seul

L'authentification (comme votre flux de connexion) est un composant sensible de votre application que vous voudrez laisser aux experts. L'utilisation d'un outil dédié pour appliquer une politique de mot de passe et offrir facilement une authentification unique ou même une authentification multifactorielle pour votre application au fur et à mesure que vous évoluez protégera vos comptes d'utilisateurs et votre réputation. 

Excellents outils : Auth0, Quasr 

Ne jamais faire sa propre cryptographie

De la même manière, la cryptographie est une expertise, il faut donc toujours s'appuyer sur des mécanismes, des bibliothèques et des outils établis. Construire vos propres implémentations, ou utiliser des drapeaux et des options que vous ne comprenez pas complètement,

vous expose à des risques importants. Les bibliothèques telles que NaCL n'offrent que peu d'options, vous limitant à de bons choix.

‍

Niveau 1

Mettre en place un pipeline CI/CD pour surveiller votre code

Mettre en œuvre un pipeline CI/CD avec des tests revient à ajouter des points de contrôle de la qualité à la chaîne de montage du code de votre application. Vous pouvez intégrer des outils d'analyse statique du code pour effectuer des tests statiques de sécurité des applications (SAST), qui analysent votre code à la recherche de failles susceptibles d'entraîner des vulnérabilités en matière de sécurité. Vous pouvez également intégrer un outil de test dynamique de la sécurité des applications (DAST, parfois appelé surveillance de la surface) pour simuler des attaques et identifier les vulnérabilités dans l'interface de votre application web (par exemple en recherchant des ports ouverts ou un trafic entrant non limité). 

Opensource DAST : ZAP

Opensource SAST : Opengrep

Contrôlez vos dépendances  

Que vous en soyez conscient ou non, la majeure partie du code qui alimente votre application est probablement tirée des projets open-source et des bibliothèques tierces sur lesquels les modèles d'IA sont entraînés. Ce sont vos dépendances, et parfois même celles-ci ont leurs propres dépendances, qui constituent toutes votre chaîne d'approvisionnement logicielle. Une seule faille dans l'une de ces bibliothèques peut mettre en péril l'ensemble de votre application, mais vous pouvez réduire les risques en utilisant les bons outils pour surveiller vos dépendances afin de détecter les vulnérabilités connues.

Outil recommandé : Trivy

L'aïkido, une solution en quelques secondes

Vérifiez que vos dépendances ne contiennent pas de logiciels malveillants

De même, votre chaîne d'approvisionnement peut inclure des paquets malveillants contenant des logiciels malveillants. Ceux-ci sont particulièrement dangereux, car les attaquants agissent généralement rapidement après avoir réussi à introduire un logiciel malveillant dans votre code. Vous devez donc également réagir rapidement. Notez que les bases de données CVE (Common Vulnerabilities and Exposures) sont trop lentes et ne vous mettront pas à l'abri de ce type d'attaques.

Outils : Aikido Intel

L'aïkido, une solution en quelques secondes

Utiliser les lockfiles pour protéger votre chaîne d'approvisionnement

Si vous n'utilisez pas de lockfiles, à chaque fois que vous construirez votre application, vous intégrerez les dernières versions de tous les paquets open-source. Les lockfiles permettent des constructions reproductibles en intégrant les mêmes versions de vos dépendances open-source. Cela permet à votre application d'être stable en cas de changements radicaux dans vos dépendances, mais protège également votre application contre les attaques de la chaîne d'approvisionnement lorsque la dernière version d'une dépendance a été compromise. Un exemple récent est la vulnérabilité tj-actions/changed-files de mars 2025 : les attaquants ont modifié le code de l'action GitHub tj-actions/changed-files, faisant en sorte que l'action compromise imprime des secrets CI/CD dans les journaux de construction des actions GitHub.

Prévenir les attaques de type "cross-site scripting" grâce à des en-têtes CSP stricts

Les en-têtes CSP peuvent vous protéger contre les attaques XSS courantes en fournissant une couche de sécurité supplémentaire qui contrôle les ressources dynamiques autorisées à être chargées. Cela empêche les attaquants d'injecter des scripts dans vos pages web.

Vérifier si vous les avez installés correctement avec l'Aïkido

Utiliser un pare-feu d'application web

Utilisez un pare-feu d'application web (WAF) ou un système d'autoprotection des applications en cours d'exécution (RASP) pour protéger les serveurs orientés vers le web contre les menaces inconnues du jour zéro, y compris les menaces inconnues d'injection SQL ou de XSS. L'outil analyse et empêche les requêtes d'utilisateurs ayant un comportement suspect ou malveillant (comme une charge utile d'injection), agissant comme une dernière ligne de défense contre les attaques. 

Les meilleurs outils : AWS WAF Aikido Zen

‍

Niveau 2

Une fois les mesures de sécurité susmentionnées mises en place, il est temps d'améliorer votre posture de sécurité.

Mettre en œuvre les meilleures pratiques pour les conteneurs

Les conteneurs empaquettent les logiciels de manière à ce qu'ils puissent fonctionner de manière fiable lorsqu'ils sont déplacés d'un environnement informatique à un autre. Ils regroupent une application et toutes ses dépendances nécessaires, telles que les bibliothèques, les cadres et les fichiers de configuration (tout ce qui fait partie de votre chaîne d'approvisionnement), en un seul paquet. Cela garantit que l'application fonctionne de manière cohérente, quel que soit l'environnement dans lequel elle est déployée. 

Si vous utilisez des conteneurs pour le déploiement, certaines bonnes pratiques vous aideront à renforcer votre application.

Maintenez vos images de base Docker à jour 

Les vulnérabilités de l'image de votre conteneur de base (le plan de ce qui compose votre conteneur) mettent votre application en danger. Téléchargez régulièrement toutes les mises à jour de sécurité pour votre image de base. Pour les serveurs, vous pouvez déléguer cette tâche à un fournisseur PaaS comme Heroku ou AWS Beanstalk.

Analysez votre sécurité Docker en utilisant : Syft Grype Trivy

L'aïkido, une solution en quelques secondes

Exécuter des conteneurs Docker avec des privilèges restreints

Des privilèges limités font qu'il est difficile pour les attaquants de prendre le contrôle de l'hôte ou de rebondir vers d'autres services. Évitez d'exécuter des conteneurs avec des rôles d'utilisateurs privilégiés, tels que root sur les systèmes Unix, ou Administrator ou System sur les systèmes Windows.

Protégez vos secrets

Séparer les secrets du code est un bon début. Si vous utilisez des conteneurs, vous devez également vous assurer que vos fichiers secrets et autres données sensibles sont correctement protégés. Cela implique d'utiliser des outils de gestion des secrets (de nombreux fournisseurs de cloud proposent les leurs), des secrets Kubernetes si vous utilisez Kubernetes, de faire tourner les secrets régulièrement et de fixer des dates d'expiration pour vos secrets. 

Outils de gestion des secrets : HashiCorp Vault AWS Secrets Manager Google Cloud Secret Manager

Lire la suite : Gérer les secrets en toute sécurité dans les conteneurs : Meilleures pratiques et stratégies

Vérifiez que vos paquets ne sont pas en fin de vie (EOL)

Au fur et à mesure que les paquets vieillissent et cessent d'être pris en charge, le risque d'exploitation augmente. Vous devez veiller à mettre à jour les paquets qui arrivent bientôt en fin de vie.

Vous pouvez également l'installer en quelques secondes grâce à la fonction de numérisation des conteneurs d'Aikido.

Mettre en œuvre les meilleures pratiques pour vos comptes cloud

Séparer les comptes de développement, de mise à l'essai et de production dans le nuage 

Tout comme vous souhaitez séparer vos branches Git de développement, de staging et de production, il en va de même pour vos comptes cloud. Bien que vous puissiez créer des réseaux virtuels à l'intérieur de vos comptes cloud pour séparer les phases de développement et de production, cela peut devenir compliqué au fur et à mesure de votre croissance, car vous devrez continuellement gérer les droits d'accès des utilisateurs pour les nouveaux développeurs. Nous recommandons de conserver l'infrastructure de développement, de mise à l'essai et de production dans des comptes cloud complètement séparés. Tous les fournisseurs de cloud computing proposent une facturation unifiée, ce qui constitue un casse-tête de moins.

Utiliser des outils de gestion de la posture dans l'informatique dématérialisée

Les fournisseurs de services en nuage offrent tellement de fonctionnalités qu'il est facile d'oublier ou de mal configurer quelque chose qui vous met en danger. Utilisez un outil de gestion de la sécurité de l'informatique dématérialisée (CSPM) pour rechercher les anomalies dans votre informatique dématérialisée.

Outils CSPM : Cloudsploit AWS Inspector

L'aïkido, une solution en quelques secondes

Activer les alertes sur le budget de l'informatique en nuage

En cas de piratage de votre compte cloud, un moyen infaillible de détecter que quelqu'un extrait des bitcoins sur votre compte est de mettre en place des alertes budgétaires pour surveiller les dépenses. Votre fournisseur de cloud devrait proposer des alertes intégrées à cet effet, ou vous pouvez configurer l 'analyse du cloud avec Aikido pour vérifier les problèmes de budget et les mauvaises configurations à risque. 

Vérifiez vos LLM pour les exploits les plus courants

En plus de construire avec des LLM, vous pouvez intégrer des LLM dans votre produit public. Vous pouvez avoir un chatbot qui offre un support aux utilisateurs, ou un assistant IA qui les aide à embarquer. Si vos clients interagissent avec un LLM sous quelque forme que ce soit, c'est une bonne idée de les tester pour les exploits les plus courants afin de ne pas exposer les clients à des risques de sécurité. 

Vérifier les exploits les plus courants : Top 10 de l'OWASP pour les LLM

Au-delà

Mettre en œuvre un cycle de développement sécurisé

Une grande partie des pratiques modernes en matière de sécurité consiste à déplacer vers la gauche les mesures de sécurité en les intégrant plus tôt dans le cycle de vie du développement. Cela permet de prendre l'habitude d'appliquer les bonnes pratiques à chaque étape du projet et de détecter les problèmes plus tôt, avant qu'ils ne constituent une menace réelle. Cela signifie qu'il faut adhérer à une liste de contrôle de sécurité comme celle-ci, se familiariser avec les failles de sécurité typiques et les détecter lors de la révision du code, et mettre en œuvre des contrôles de sécurité sur les demandes d'extraction également. 

En savoir plus : Top 10 de l'OWASP

Pour en savoir plus : Article de Wikipédia sur le cycle de vie du développement des systèmes

Tout le monde peut être victime d'une cyberattaque - même les multinationales dotées d'un service de sécurité spécialisé sont toujours exposées à des violations. Bien que le code vibratoire ne soit pas sécurisé par défaut, l'adoption de bonnes pratiques en matière de sécurité dès le départ vous permet de vous abandonner pleinement aux vibrations. Ce que vous construisez en vaut la peine. 

Pour en savoir plus

• Liste de contrôle d'Aikido sur la sécurité des CTO SaaS en 2025
• Le guide Open Source de la sécurité des applications pour les startups

‍