Stage de BUT2 : automatisations et sécurité réseau

Contexte

Mon stage de deuxième année de BUT Informatique s’est déroulé sur onze semaines, 392 heures, au sein d’une très petite entreprise lyonnaise du secteur de la veille billetterie événementielle. Le service fonctionne par abonnement : des programmes surveillent en continu une soixantaine de sources, détectent l’information utile sur la disponibilité de billets, la diffusent aux membres, puis les assistent dans l’acquisition. Les comptes utilisés pendant le stage étaient ceux des abonnés de ce service de veille, avec leur consentement.

J’étais encadré par un tuteur en entreprise et une référente à l’IUT, et je travaillais avec deux collaborateurs à distance, dans d’autres pays. Par confidentialité, je ne nomme ni les sources ni les plateformes concernées : ces détails n’ajoutent rien à la compréhension de mon travail.

Le problème

Ma mission avait deux volets liés. Le premier était de maintenir et fiabiliser l’existant : une chaîne de collecte écrite en Python, qui doit rester opérationnelle en permanence malgré l’évolution constante des sources. Le second était de construire de nouveaux modules d’automatisation en Go, le langage retenu par l’entreprise pour ces composants.

Derrière les deux se cachait une même difficulté : les échanges réseau entre mes programmes et les services distants réussissent ou échouent selon un contexte peu lisible, où une requête dépend de celles qui l’ont précédée.

Déroulé du stage

Le stage s’est déroulé en cinq phases, de mai à juillet 2026, de l’analyse à la maintenance. Elles se chevauchent en partie.

Démarche et décisions

J’ai travaillé par itérations courtes : analyser, capturer et observer le réseau, architecturer, coder, tester pas à pas, isoler la cause d’un blocage, comparer à une référence, corriger, recommencer. Chaque dépôt Git garde la trace de cette progression.

Vue d’ensemble, la chaîne technique allait de la capture du trafic jusqu’à la supervision du module. Chaque rejet réseau observé renvoyait à l’étape d’analyse : le diagnostic était permanent.

Sur la collecte Python, la première tâche a été de corriger le point d’entrée dont un défaut perturbait la diffusion vers la communauté. Le reste du stage, j’ai diagnostiqué les défaillances source par source et mis à jour l’analyse syntaxique quand un site changeait sa structure. La collecte a tenu malgré l’évolution des sources.

Le premier gros module, en Go et parti de zéro, réalisait un workflow d’authentification puis de réservation sur un service tiers. Je l’ai pris de bout en bout : analyse du service, capture du trafic réseau comme référence, conception, implémentation, puis tests incrémentaux jusqu’à lever chaque blocage. Il a atteint un état fonctionnel.

Analyse réseau et sécurité

Le module devait respecter le protocole observé dans le trafic capturé. L’ordre, les valeurs et la complétude des en-têtes comptaient, et les paramètres TLS devaient rester constants d’un bout à l’autre de la session. Mon outil principal de diagnostic était la comparaison à une capture de référence : repérer, octet après octet, où ma requête divergeait de l’échange observé.

Le comparateur ci-dessous rejoue cette méthode sur une requête fictive : décochez un choix d’implémentation, les octets qui s’écartent de la référence passent en rouge et le serveur cesse d’accepter la requête.

J’ai consacré une semaine à lire un script côté client pour en comprendre la logique.

Piloter un assistant de programmation par IA

L’entreprise m’a confié un assistant de programmation par IA. Au début, je l’utilisais mal : je lui envoyais tout, sans cadrer le problème, en attendant qu’il décide à ma place. J’ai avancé ainsi jusqu’à environ 60 % du premier module, puis un blocage net, impossible à dépasser de cette manière.

Quand je négligeais le contexte, l’assistant inventait ; quand je formulais mal le problème, il esquivait la vraie difficulté. J’ai alors pris le temps de comprendre moi-même les mécanismes du domaine, puis j’ai reformulé les problèmes. Dès lors, je décidais et je vérifiais ce que l’assistant produisait, jusqu’à terminer le module.

Sur la durée du stage, j’ai repris et maintenu une chaîne de collecte Python d’environ 26 000 lignes. J’ai produit de zéro un module Go d’environ 3 200 lignes.

Ce que j’ai appris, ce que je referais

J’ai mené un module complet en partant de zéro, sur un langage et un domaine que je ne connaissais pas. Ma principale limite, dont j’ai pris conscience pendant le stage, a été d’avancer plus vite que ma compréhension réelle ; j’ai appris à consolider, à m’assurer d’avoir compris une étape avant d’en empiler une autre. J’ai aussi découvert le travail en équipe distribuée : communication asynchrone, autonomie, traçabilité.

Ce stage a donné un sens concret à des notions parfois abstraites en cours — réseau, analyse de protocole, sécurité appliquée — et m’a confirmé mon intérêt pour la sécurité et le développement bas niveau. Pour la suite, je veillerai à consolider au fur et à mesure.