Audits de sécurité pour les logiciels et les systèmes d’IA
Nous examinons comment vos systèmes gèrent les données, les accès, les secrets et les risques propres à l’IA, puis vous remettons une liste classée et corrigeable, pas un rapport de scan générique.
Nous sommes une firme de conseil en IA et de logiciels sur mesure à Limassol, travaillant avec des équipes à Chypre et dans l’ensemble de la région EMEA. Un audit de sécurité ici est une revue concrète de la façon dont un vrai système est construit : son architecture, son traitement des données, qui peut faire quoi, où vivent les secrets, ce dont il dépend, et les risques propres à l’IA, comme l’injection de prompt, la fuite de données, et les réponses qui ne sont pas fondées sur vos propres sources.
Ceci est une revue, pas un certificat. Nous ne vendons pas des pentests à l’heure ni des badges de conformité. Nous lisons le système comme les personnes qui l’ont construit auraient dû le faire, et nous le tenons au même standard de production que celui que nous appliquons à notre propre produit.
La faille reste discrète jusqu’à ce que quelqu’un la trouve
La plupart des problèmes de sécurité dans les logiciels ne sont pas exotiques. C’est une clé d’API commitée dans un dépôt, un rôle de base de données qui peut lire plus qu’il ne devrait, une intégration qui fait confiance à une entrée qu’elle ne vérifie jamais, une dépendance trois versions derrière un correctif connu. Le système fonctionne, fait une belle démo et part en production. La faille reste discrète jusqu’à ce que quelqu’un la trouve.
Les systèmes d’IA ajoutent une seconde couche que la plupart des revues ratent entièrement. Un copilot relié à vos documents peut être amené à ignorer ses instructions. Un système de récupération peut faire remonter un enregistrement que le demandeur n’était jamais censé voir. Une réponse de modèle peut être faussement assurée sans aucune trace jusqu’à une source. Ce ne sont pas des cas marginaux. Ce sont les modes de défaillance prévisibles du fait de mettre un modèle devant de vraies données, et ils doivent être revus délibérément.
Cinq choses que nous tenons à un standard de production
Les chemins d’IA reçoivent la même rigueur que le code qui les entoure, car c’est là que la plupart des revues s’arrêtent trop tôt.
- ARCH
Architecture et flux de données
Nous cartographions comment les données circulent réellement dans le système, où elles sont stockées, où elles franchissent une frontière de confiance, et où elles quittent l’UE, pour que les risques soient visibles au lieu d’être supposés.
- ACCESS
Contrôle des accès et secrets
Nous vérifions qui peut faire quoi, si les rôles sont limités au travail, et si les clés et identifiants vivent dans des variables d’environnement et un coffre à secrets plutôt que dans le code ou un fichier de configuration.
- DEPS
Dépendances et chaîne d’approvisionnement
Nous examinons les bibliothèques et services dont vous dépendez pour y détecter les vulnérabilités connues, les paquets non maintenus, et ceux qui tirent plus que nécessaire.
- AI RISK
Risque propre à l’IA
Injection de prompt, fuite de données via un modèle, récupération qui renvoie des enregistrements que le demandeur ne devrait pas voir, et réponses qui ne sont pas fondées sur une source citable, examinés comme leur propre classe de risque.
- EU AI ACT
Obligations de l’EU AI Act
Nous signalons là où un système porte des obligations au titre de l’EU AI Act, comme la journalisation, la supervision humaine et la transparence, pour qu’elles soient conçues dès le départ plutôt que découvertes plus tard lors d’un audit.
Une liste classée, pas un mur d’avertissements équivalents
Chaque constat porte une gravité, une description claire et le correctif. Vous travaillez de haut en bas, du problème le plus susceptible de faire mal à celui qui peut attendre. Ce sont les formes de problèmes que nous trouvons, pas un déversement de scanner.
- Élevée
Clé d’API commitée dans l’historique du dépôt
Faire tourner et déplacer vers un coffre à secrets - Élevée
La récupération peut renvoyer des enregistrements que le demandeur ne devrait pas voir
Limiter la récupération au demandeur - Moyenne
Le rôle de base de données lit plus de tables que le travail ne l’exige
Resserrer au moindre privilège - Moyenne
Les réponses du modèle ne renvoient à aucune source
Fonder les réponses sur des citations - Faible
Dépendance trois versions derrière un correctif connu
Corriger au prochain cycle
Auditer, classer, corriger, transférer
Audit
Nous lisons le système : code, architecture, traitement des données, accès, dépendances et chemins d’IA. Nous partons de son fonctionnement réel, pas d’un questionnaire, et nous remontons ce que nous trouvons au fur et à mesure.
Classement
Nous transformons les constats en une liste classée, chacun avec son impact réel, sa probabilité d’être atteint, et un correctif concret. Vous obtenez un ordre clair de travail, pas un mur d’avertissements de poids égal.
Correction
Là où vous le souhaitez, nous apportons les changements nous-mêmes : combler la faille d’accès, déplacer le secret, fonder la récupération, corriger la dépendance. Chaque correctif est revu et testé, comme tout projet que nous livrons.
Transfert
Vous obtenez le rapport, les correctifs et le raisonnement, documentés pour que votre équipe poursuive le travail et détecte les mêmes problèmes la prochaine fois sans nous.
Ce qui atterrit sur votre bureau
Un rapport de constats classés
Chaque problème trouvé, ordonné par impact et probabilité, chacun avec une explication claire et un correctif concret, pas un déversement brut de scanner.
Des correctifs, là où vous le souhaitez
Nous refermons les problèmes que l’on nous demande de refermer, revus et testés, pour que le rapport ne reste pas dans un tiroir comme une liste de choses à faire un jour.
Une revue du risque IA
Une lecture claire de l’exposition propre à l’IA : injection de prompt, fuite de données, ancrage de la récupération, et comment les données sont traitées, avec ce qu’il faut changer pour chacun.
Une lecture EU AI Act et résidence des données
Là où le système porte des obligations au titre de l’EU AI Act, et où se trouvent vos données, pour que les questions de conformité aient des réponses honnêtes avant que quelqu’un d’officiel ne les pose.
Un transfert utilisable par votre équipe
Les constats, les correctifs et le raisonnement documentés, pour que la prochaine revue parte d’ici plutôt que de zéro.
Nous tenons votre système au même standard que notre propre produit, Pileform, qui tourne en production dans 55 juridictions de TVA et 11 langues, en lisant et rapprochant des documents financiers sous de vraies obligations de traitement des données. Nous avons construit nous-mêmes la version auditable, hébergée dans l’UE et fondée sur des citations d’un système d’IA, c’est la même discipline que nous apportons à votre Document AI et aux systèmes qui l’entourent.
Voir comment cela se relie à notre travail de Document AIAvant une revue de sécurité, expliqué
Est-ce un test d’intrusion ?
Non. Un pentest tente d’entrer depuis l’extérieur et vous dit ce qui a marché. Nous examinons le système de l’intérieur : son architecture, le traitement des données, les accès, les secrets, les dépendances et les chemins d’IA, pour que vous voyiez les risques structurels, pas seulement ceux qu’un attaquant a réussi à atteindre ce jour-là. Les deux sont complémentaires, et nous dirons si un pentest est la meilleure étape suivante dans votre cas.
Délivrez-vous une certification ou un badge de conformité ?
Non, et nous ne prétendrons pas le faire. Nous sommes des ingénieurs qui examinent comment un système est construit, pas un organisme certificateur. Ce que nous vous donnons est une image honnête et classée des vrais risques et de leurs correctifs. Si vous avez besoin d’une certification formelle, un audit comme celui-ci est une bonne préparation, mais ce n’en est pas un substitut.
Que couvre concrètement la partie propre à l’IA ?
Injection de prompt, fuite de données via un modèle, récupération qui renvoie des enregistrements que le demandeur ne devrait pas voir, réponses qui ne sont pas fondées sur une source citable, et comment vos données sont stockées et utilisées. Ce sont les modes de défaillance prévisibles du fait de mettre un modèle devant de vraies données, et nous examinons chacun comme sa propre classe de risque.
Vous contentez-vous de signaler les problèmes, ou les corrigez-vous ?
Les deux, et la correction est l’essentiel. Nous classons ce que nous trouvons, puis refermons les problèmes que vous voulez refermer, revus et testés. Un rapport sur lequel personne n’agit vaut peu, alors nous sommes conçus pour agir dessus avec vous plutôt que de vous remettre une liste et partir.
Pouvez-vous examiner un système que vous n’avez pas construit ?
Oui. La plupart des systèmes que nous auditons ne sont pas les nôtres. Nous lisons le code et l’architecture tels qu’ils sont, raison pour laquelle l’étape d’audit vient en premier : nous partons du fonctionnement réel du système, pas d’une documentation qui peut être périmée.
Où vont nos données pendant la revue, et restent-elles dans l’UE ?
Vos données restent les vôtres et restent là où elles sont. Nous examinons dans votre environnement sous vos contrôles d’accès, et la résidence des données est l’une des choses que nous vérifions plutôt que quelque chose que nous mettons en péril. Nous sommes une firme enracinée en Europe et concevons pour la résidence des données dans l’UE par défaut, y compris dans le travail de Document AI auquel cela se relie souvent.
Dites-nous ce que vous voulez faire examiner
Un projet sur mesure qui passe en production, un système d’IA sur le point de toucher de vraies données, ou une plateforme dont vous avez hérité et à laquelle vous ne faites pas pleinement confiance. Nous la lirons honnêtement, classerons ce que nous trouvons, et corrigerons ce que vous voulez corriger.
Tenu au même standard de production que le produit que nous exploitons nous-mêmes.