AnonyNER · N°2
Cartographier les logs disponibles : le problème du corpus pour l’anonymisation Entraîner un agent d’anonymisation pose un problème paradoxal : les données les plus utiles à l’entraînement sont précisément celles que personne ne partage. Les logs réels de production contiennent exactement les entités sensibles qu’on cherche à détecter — et c’est pour ça qu’ils restent dans les datacenters.
Cette contrainte a des conséquences directes sur la qualité des modèles. Cet article recense les corpus disponibles, leur niveau de sanitisation, leur densité en entités sensibles, et la façon dont on peut les compléter par des données synthétiques.
AnonyNER · N°3
Entraîner un NER sécurité : du corpus annoté au modèle en production Les entités de sécurité que spaCy standard ne détecte pas ne sont pas impossibles à apprendre — elles sont simplement absentes de ses données d’entraînement. La solution n’est pas de remplacer spaCy par un LLM lourd, mais d’entraîner le composant NER de spaCy sur des exemples spécifiques au domaine.
Ce chemin — annotation LLM-assistée → fine-tuning spaCy → modèle production léger — est à la fois robuste et déployable sans GPU.
AnonyNER · N°4
Recollect & Rank : quand un LLM désanonymise vos logs Une opération d’anonymisation réussie au sens technique — toutes les IPs masquées, tous les comptes remplacés par des tokens — peut échouer au sens de la confidentialité si le contexte restant permet de reconstruire ce qui a été masqué. Ce n’est pas une hypothèse théorique. Les outils pour y parvenir sont disponibles publiquement.
Le problème des quasi-identifiants La définition classique du PII (Personally Identifiable Information) couvre les données directement identifiantes : nom, numéro de sécurité sociale, adresse email.
AnonyNER · N°5
La session partagée : garantir la cohérence d’anonymisation sur un batch de logs Anonymiser un fichier de logs est résolu. Anonymiser un batch de fichiers de logs de manière cohérente — même entité, même token, partout — est un problème d’architecture non trivial que les outils standards ne résolvent pas.
C’est pourtant la condition minimum pour que les logs anonymisés restent exploitables par leur destinataire.
Le cas d’usage qui impose la contrainte L’infrastructure rencontre un problème critique.
LoRA Factory · N°1
L’Usine à Cerveaux : Automatiser la Spécialisation des LLM Dans le paysage actuel de la cybersécurité, la réactivité n’est plus une option ; c’est une question de survie. Un analyste SOC (Security Operations Center) moderne doit jongler entre une multitude d’interfaces : SIEM (Wazuh), plateformes d’orchestration (TheHive/Cortex), firewalls de nouvelle génération (OPNsense/Stormshield), et outils de threat intelligence (MISP).
L’idée d’un “Agent de Sécurité IA” capable d’unifier ces interfaces est séduisante, mais elle se heurte à un obstacle de taille : la précision technique absolue.
LoRA Factory · N°2
Apprendre à l’IA à “Réfléchir” : Le Moteur de Traces ReAct Dans l’article précédent, nous avons vu comment lora-factory transforme des spécifications OpenAPI en contrats techniques rigides via Pydantic. Aujourd’hui, nous plongeons dans le “carburant” de nos experts : la donnée synthétique de haute qualité.
Entraîner un modèle sur de simples couples “Question -> Appel API” est l’erreur la plus commune dans le monde du fine-tuning. Cela crée des modèles “parrots” (perroquets) qui s’effondrent dès que la requête utilisateur s’écarte du script nominal ou contient des ambiguïtés.
LoRA Factory · N°3
La Forge Technique : Optimiser l’Entraînement avec Unsloth & QLoRA Une fois que nous disposons de données de haute qualité (le dataset ReAct de l’Article 2), il est temps de passer à la “forge”. Fine-tuner un modèle de 12 milliards de paramètres (comme Mistral-Nemo-12B) n’est pas une mince affaire sur du matériel grand public. Sans optimisation extrême, l’entraînement d’un expert métier pourrait prendre des heures, ce qui briserait le cycle d’itération rapide indispensable à notre usine.
LoRA Factory · N°4
Du Modèle au Système : Orchestration & Validation “Bare-Metal” Entraîner un adaptateur LoRA performant (Article 3) est une étape cruciale, mais en cybersécurité, un modèle isolé n’est qu’un composant passif. Pour qu’il soit réellement utile et sûr, l’expert doit être intégré dans un système d’orchestration capable de planifier des actions, de gérer des dépendances complexes, et surtout, de prouver son efficacité sur du matériel réel.
Pour transformer nos modèles en agents opérationnels, nous utilisons deux piliers technologiques : LangGraph pour le cerveau cognitif et Hyper-V pour la validation sur le terrain (Façon de parler).
LoRA Factory · N°5
L’IA au Service de l’Infrastructure : Extension IaC & Vision Future Dans les articles précédents, nous avons exploré comment lora-factory transforme les APIs d’outils de sécurité en agents intelligents. Pour conclure cette série, nous allons voir comment cette même technologie s’étend à un pilier fondamental de l’informatique moderne : l’Infrastructure as Code (IaC).
Le pipeline de l’Usine à LoRAs est par nature modulaire. Au lieu d’ingérer une spécification OpenAPI, nous avons appris au moteur à ingérer des patterns de code Ansible (YAML) et Terraform (HCL).
LoRA Factory · N°6
Affiner sans Oublier : Itération Continue et Mémoire du LoRA Dans les articles précédents, nous avons posé les fondations : générer des traces ReAct de qualité, entraîner efficacement avec QLoRA et Unsloth, orchestrer les agents sur du matériel réel. Mais une question reste entière : que se passe-t-il quand le premier agent certifié n’est pas assez bon ?
C’est le lot commun du fine-tuning sur domaine étroit. Un premier run d’entraînement produit un agent fonctionnel, mais la validation fonctionnelle — le vrai test, pas la loss — révèle des angles morts.
Note Article importé du site Source
Cet article est la version Française de Petits modèles linguistiques : Un guide avec des exemples | DataCamp par Auteur Inconnu.
Que sont les petits modèles linguistiques ? Les petits modèles linguistiques sont les versions compactes et très efficaces des grands modèles linguistiques massifs dont nous avons tant entendu parler. Les LLM comme le GPT-4o ont des centaines de milliards de paramètres, mais les SML en utilisent beaucoup moins, généralement de l’ordre de quelques millions à quelques milliards.
Architecture et Dynamique Opérationnelle des Contrôleurs d’Ingress Kubernetes L’évolution de l’écosystème Kubernetes a redéfini la manière dont les applications modernes sont exposées aux réseaux externes. Dans une architecture de microservices, la gestion du trafic entrant ne se limite plus à un simple routage de paquets, mais englobe désormais des fonctionnalités complexes de couche 7, telles que la terminaison TLS, l’équilibrage de charge intelligent, et le routage basé sur le contenu.1 L’Ingress Kubernetes, et plus spécifiquement le contrôleur d’Ingress, constitue la pièce maîtresse de cette infrastructure de connectivité, agissant comme le point d’entrée unique et programmable pour tout trafic nord-sud au sein du cluster.
