Les cyberattaques ne frappent plus seulement les grandes entreprises. Les startups et ETI, avec leurs infrastructures cloud rapides et leurs équipes réduites, sont devenues des cibles de choix. À travers les cas Axios, Vertex et FICOBA, cet article explore le paradoxe des équipes qui innovent sur des fondations fragiles et comment construire autrement.

83 millions de téléchargements par semaine. C’est le rythme auquel Axios, bibliothèque JavaScript invisible pour le grand public mais cruciale pour des millions d’applications, irriguait l’écosystème numérique mondial. Mardi 1ᵉʳ avril 2026, cette infrastructure silencieuse s’est transformée en cheval de Troie. Deux versions piégées. Un logiciel malveillant capable de s’exécuter sur macOS, Windows et Linux. Une compromission planifiée 18 heures à l’avance, conçue pour effacer ses propres traces après infection. Cette attaque n’est pas anecdotique. Elle est symptomatique d’une réalité que les startups technologiques refusent encore de voir : leurs fondations reposent sur du sable mouvant. Pendant qu’elles gagnent en vélocité grâce aux agents de code IA, leur surface d’attaque explose. Pendant qu’elles déploient en quelques jours ce qui prenait des mois, leur dette sécuritaire s’accumule en silence. La sécurité ne peut plus être traitée comme une contrainte qu’on gère après coup. Elle demande une posture fondamentalement différente intégrée dès la conception, et pensée comme une condition de durabilité du produit.

I. L’onde de choc : quand l’infrastructure devient arme

Google Threat Intelligence ne s’embarrasse pas de nuances : « L’impact de cette attaque est vaste et entraîne un effet domino, car d’autres bibliothèques très utilisées s’appuient sur Axios. » La Corée du Nord, via le groupe UNC1069 et son malware WAVESHAPER.V2, ne visait pas une entreprise. Elle ciblait l’écosystème.

La même semaine, Vertex AI, service d’intelligence artificielle de Google Cloud utilisé massivement par les startups pour leurs modèles ML, révélait qu’une simple mauvaise configuration d’un agent pouvait exposer un environnement cloud entier. Quelques jours plus tard, le fichier FICOBA français, 1,2 million de comptes bancaires, tombait entre des mains malveillantes.

Nous ne sommes plus dans une ère de failles isolées, mais de contamination systémique.

II. Le paradoxe des startups : innover sur du verre brisé

Les startups construisent sur l’open source. Elles utilisent Axios, React, Node.js, des briques maintenues souvent par une poignée de développeurs bénévoles. Cette architecture distribuée crée une dépendance invisible mais totale envers des infrastructures fragiles.

Le paradoxe est brutal : pour aller vite, impératif de survie dans l’univers startup, elles accumulent une dette sécuritaire massive.

Selon notre étude menée auprès de startups françaises :

• 50% n’ont aucun responsable sécurité formellement désigné
• 62,5% allouent moins de 5% de leur budget IT à la cybersécurité
• 0% ont un plan de continuité d’activité documenté et testé

Cette négligence n’est pas un choix mais une contrainte. Les investisseurs financent la croissance, pas la sécurité. Les équipes techniques se concentrent sur le produit, pas sur la résilience. Aujourd’hui, avec GitHub Copilot, Cursor, et autres agents de code, une startup peut déployer en une semaine ce qui prenait trois mois. Mais cette vélocité amplifie le risque : plus de code produit, plus de dépendances, plus de surface d’attaque. Sans gouvernance sécuritaire.

Ce n’est pas un défaut de bonne volonté. C’est un défaut de méthode.

III. La fausse promesse du cloud : sécurité par délégation

94% des entreprises hébergent au moins une partie de leurs données dans le cloud. Depuis 2020, 79% d’entre elles ont subi au moins une violation. La migration vers AWS, Google Cloud ou Azure crée l’illusion de sécurité par proxy. Les startups confondent infrastructure managée et sécurité garantie. L’attaque sur Vertex AI le démontre : même les services les plus avancés deviennent vulnérables dès qu’ils sont mal configurés.

C’est précisément ici que la question de la souveraineté opérationnelle devient centrale. Maîtriser son contexte technique, c’est savoir ce qui tourne dans son environnement et comprendre les dépendances qu’on accepte

Chez La Forge, c’est une question qu’on se pose à chaque projet : est-ce que l’équipe cliente comprend ce qu’elle opère ? Un produit IA qu’on ne comprend plus est un produit qu’on ne maîtrise plus.

IV. Comment un Forgeron aborde la sécurité quand il construit un produit IA

La cybersécurité entre dans nos réflexions dès le BUILD, et structure une partie du RUN.

Dans le BUILD, quelques que l’on s’applique :

• Minimiser les dépendances : on n’intègre pas une bibliothèque parce qu’elle est populaire. On se demande si elle est maintenue, auditée, et si on peut s’en passer.
• Tracer ce qu’on déploie : chaque brique technique doit être documentée, versionnée, observable. Pas juste pour faire de la conformité, mais pour pouvoir réagir vite si quelque chose change.
• Considérer les agents IA comme des vecteurs d’attaque potentiels : un agent mal paramétré peut exposer bien plus qu’une API mal configurée. La question du scope de ses permissions est critique dès la conception.

Dans le RUN, la sécurité devient une question d’observabilité et de gouvernance :

• Qui a accès à quoi ? Est-ce que les droits accordés en développement ont été révisés avant la mise en production ?
• Est-ce qu’on surveille les comportements anormaux, ou est-ce qu’on attend qu’un incident nous prévienne ?
• Est-ce que l’équipe cliente a les moyens de comprendre ce qui tourne dans son environnement, ou est-ce qu’on a créé une dépendance opaque ?

Dans nos missions Partenaire IA, l’un de nos objectifs est précisément de transférer cette maîtrise, pas seulement le code, mais la compréhension de ce qu’on a construit et pourquoi.

V. Conclusion

Axios est tombé en une nuit. Une bibliothèque centrale pour des millions d’applications, compromise via une attaque planifiée, sans que personne dans la chaîne ne soit directement visé.

Ce n’est pas une raison de paniquer. C’est une raison de construire autrement.

La sécurité n’est pas incompatible avec la vélocité. Elle demande simplement qu’on l’intègre comme un paramètre de conception, dès le départ , au même titre que la performance ou l’expérience utilisateur (UX). Les équipes qui y arrivent ne font pas moins vite, elles font plus solidement. Et dans un contexte où les agents IA multiplient la capacité de production, cette solidité devient une vraie différenciation. Pas un frein. Une fondation.

Références

• ANSSI. (2025). Panorama de la cybermenace 2025.
• CNIL. (2025). Notifications de violations de données personnelles.
• Gartner. (2025). Supply Chain Attack Predictions.
• Google Threat Intelligence. (2026). Axios Compromise Analysis.
• IBM. (2025). Cost of a Data Breach Report.
• Verizon. (2025). Data Breach Investigations Report (DBIR).