Rapport de stage — BTS Services informatiques aux organisations, option SISR (solutions d'infrastructure, systèmes et réseaux), première année — environ 3 000 mots. À lire pour sa démarche, puis à transposer à une autre entreprise et à d'autres missions (établissement et personnes fictifs, exemple pédagogique).
Introduction
Mon tout premier ticket tenait en une phrase : « Plus rien ne marche au cabinet. » Derrière cette alerte se cachait un problème modeste — une box internet redémarrée qui avait perdu ses réservations d'adresses, de sorte que l'imprimante et le logiciel de rendez-vous ne se trouvaient plus — mais aussi une leçon que j'ai retrouvée tout au long du stage : pour un utilisateur, l'informatique fonctionne ou ne fonctionne pas, et c'est au technicien de traduire cette inquiétude en diagnostic.
Mon stage de première année s'est déroulé sur cinq semaines chez Opalis Infogérance, une entreprise d'une quinzaine de salariés installée dans une ville moyenne de l'Ouest. Opalis assure la maintenance informatique, la gestion des réseaux et la sauvegarde des données de petites structures : cabinets médicaux et paramédicaux, études notariales, artisans, PME industrielles et quelques communes rurales. J'ai été intégré au pôle systèmes et réseaux, sous la responsabilité de M. R., technicien supérieur et mon tuteur.
J'avais choisi l'option SISR parce que l'infrastructure m'attire davantage que le développement : comprendre comment une information circule d'un poste à un serveur, et comment on la protège en chemin. Mes objectifs étaient de découvrir le support aux utilisateurs en conditions réelles, d'administrer un annuaire Active Directory, de participer à la supervision et aux sauvegardes, et de mener un projet réseau de l'étude jusqu'à la mise en service.
Ce rapport présente d'abord l'entreprise et ses outils, puis détaille mes missions, avant d'examiner de près un projet : la segmentation du réseau d'un cabinet de kinésithérapie. Un bilan relie enfin ces expériences aux blocs de compétences du BTS et à mon projet professionnel.
Sommaire
- Première partie — Opalis Infogérance, un prestataire de proximité
- Activité et clientèle
- Organisation des équipes
- Les outils et les règles de travail
- Deuxième partie — Mes missions au quotidien
- Le support de premier niveau
- L'administration des comptes et des postes
- Le contrôle des sauvegardes et la supervision
- La préparation d'une maquette en laboratoire
- Troisième partie — Projet analysé : découper en VLAN le réseau d'un cabinet de santé
- Le constat de départ
- La conception
- La mise en œuvre
- Les imprévus et leur résolution
- Regard critique
- Quatrième partie — Ce que ces cinq semaines m'ont appris
- Conclusion
- Remerciements
- Annexes
Il reste 2 611 mots (≈9 pages) de ce document
Accès illimité à 2 630 travaux
3 €/mois, résiliable en un clic
Paiement sécurisé Stripe
Déjà abonné ? Se connecter
Première partie — Opalis Infogérance, un prestataire de proximité
Activité et clientèle
Opalis vend principalement des contrats d'infogérance : en échange d'un forfait mensuel, l'entreprise prend en charge la maintenance du parc informatique d'un client, la surveillance de ses serveurs, ses sauvegardes et l'assistance à ses utilisateurs. À côté de ces contrats, elle réalise des interventions ponctuelles (installation d'un réseau dans de nouveaux locaux, renouvellement d'un parc de postes) et revend du matériel.
La clientèle se compose de structures qui n'ont pas de service informatique interne. Leur point commun est qu'elles dépendent entièrement de leurs outils numériques sans avoir les moyens de les gérer elles-mêmes : une étude notariale ne peut pas signer un acte si son logiciel métier est indisponible, un cabinet médical ne peut pas recevoir ses patients sans son agenda en ligne. Le métier d'Opalis consiste donc autant à prévenir les pannes qu'à les réparer.
Une particularité m'a frappé dès la première semaine : une part importante des clients relève du secteur de la santé. Les données qu'ils manipulent sont des données de santé, particulièrement protégées par le RGPD. Lorsqu'elles sont hébergées à l'extérieur du cabinet, elles doivent l'être chez un hébergeur certifié pour ce type de données. Cette contrainte influence toutes les décisions techniques chez ces clients.
Organisation des équipes
L'entreprise est dirigée par son fondateur, qui assure aussi une partie de la relation commerciale. Les équipes techniques sont réparties en deux pôles :
| Pôle | Rôle | Effectif approximatif |
|---|---|---|
| Support (niveau 1) | Réception des appels et des tickets, résolution des incidents simples, prise en main à distance | 4 techniciens |
| Systèmes et réseaux (niveau 2) | Serveurs, réseaux, sécurité, projets, interventions sur site | 5 techniciens |
| Administration et commerce | Devis, facturation, achats de matériel, suivi des contrats | 4 personnes |
Les incidents qui dépassent le niveau 1 sont escaladés au niveau 2, avec un historique écrit dans le ticket. Cette organisation, classique dans les services informatiques, évite que les techniciens les plus spécialisés soient interrompus par des demandes simples.
Les outils et les règles de travail
L'outil central est GLPI, logiciel libre de gestion de parc et de tickets. Chaque demande y est enregistrée, catégorisée, priorisée et associée au matériel concerné. Les techniciens disposent aussi d'un logiciel de prise en main à distance, d'un outil de supervision qui interroge en permanence les serveurs et équipements des clients, d'un wiki interne où chaque client possède une fiche (schéma réseau, adresses, contacts, particularités) et d'un gestionnaire de mots de passe partagé, auquel l'accès est attribué par client.
Trois règles m'ont été présentées le premier jour. Aucun mot de passe ne s'écrit ailleurs que dans le gestionnaire. Aucune intervention ne se fait sans ticket, même pour « une minute ». Enfin, toute réinitialisation de mot de passe demandée par téléphone donne lieu à un rappel de l'utilisateur sur un numéro déjà connu, pour éviter qu'un inconnu se fasse passer pour un salarié. J'ai signé la charte informatique de l'entreprise et un engagement de confidentialité.
Deuxième partie — Mes missions au quotidien
Le support de premier niveau
Pendant les deux premières semaines, j'ai partagé mes matinées avec l'équipe de support. J'ai d'abord observé, puis traité moi-même les tickets les plus simples, toujours relus par un technicien avant clôture. J'en ai traité une soixantaine, dont voici quelques exemples représentatifs.
- Une imprimante « hors ligne » dans une PME : le pilote pointait vers une ancienne adresse IP après le remplacement d'un switch. J'ai corrigé le port d'impression et proposé de créer une réservation DHCP pour éviter la récidive.
- Une messagerie qui refuse d'envoyer : la boîte d'une secrétaire avait atteint son quota. J'ai expliqué comment archiver les anciens messages et signalé au client la possibilité d'augmenter l'espace.
- Un compte verrouillé après plusieurs erreurs de saisie : après rappel de l'utilisatrice sur sa ligne habituelle, j'ai déverrouillé le compte dans la console Active Directory et vérifié qu'aucune tentative suspecte ne figurait dans les journaux.
Ce travail m'a appris à rédiger un ticket utile : décrire ce que l'on a constaté, ce que l'on a fait et ce qui reste à faire, de sorte qu'un collègue puisse reprendre le dossier sans rappeler le client. Au début, mes comptes rendus tenaient en trois mots ; mon tuteur m'a fait réécrire les premiers jusqu'à ce qu'ils soient compréhensibles par quelqu'un qui n'avait pas assisté à l'intervention.
L'administration des comptes et des postes
Plusieurs clients disposent d'un domaine Active Directory. J'ai été chargé, sur procédure écrite, de l'arrivée et du départ des salariés chez deux d'entre eux. Pour une arrivée : création du compte dans la bonne unité d'organisation, ajout aux groupes qui donnent accès aux dossiers partagés, création de la boîte de messagerie, puis vérification à la première connexion que les lecteurs réseau et les imprimantes apparaissaient bien grâce aux stratégies de groupe. Pour un départ : désactivation du compte (et non suppression immédiate), retrait des groupes, redirection temporaire de la messagerie vers le responsable, conformément à la demande écrite du client.
J'ai également participé au renouvellement de huit postes dans une entreprise de menuiserie. Nous avons préparé une image système de référence, intégré les postes au domaine, puis transféré les données de chaque utilisateur. J'ai rédigé une liste de contrôle pour chaque poste (session ouverte, imprimantes, logiciels métier, sauvegarde des anciens fichiers, effacement sécurisé de l'ancien disque), ce qui a évité d'oublier un détail lors de la livraison sur site.
Le contrôle des sauvegardes et la supervision
Chaque matin, un technicien vérifie les rapports de sauvegarde de tous les clients. J'ai assuré cette tâche pendant trois semaines. La plupart du temps, il s'agit de constater que tout est vert ; l'intérêt de l'exercice apparaît le jour où ce n'est pas le cas.
Lors de ma troisième semaine, j'ai remarqué qu'un client n'apparaissait plus dans le rapport. Il ne s'agissait pas d'un échec signalé, mais d'une absence de rapport, beaucoup plus facile à manquer. En remontant l'historique, j'ai constaté que la sauvegarde de son serveur de fichiers vers le NAS ne s'exécutait plus depuis neuf jours : le disque de destination était plein, car la durée de conservation des copies avait été allongée sans que la capacité suive. Avec mon tuteur, nous avons libéré de l'espace selon une politique de rétention corrigée, relancé une sauvegarde complète, puis effectué un test de restauration d'un dossier pour vérifier que la copie était exploitable. Une alerte « aucune sauvegarde depuis vingt-quatre heures » a ensuite été ajoutée dans l'outil de supervision.
Cet épisode illustre la règle dite « 3-2-1 » que l'on étudie en cours (trois copies, sur deux supports différents, dont une hors site) : une sauvegarde n'existe vraiment que si l'on a vérifié qu'on peut la restaurer.
La préparation d'une maquette en laboratoire
Opalis dispose d'un petit laboratoire : un serveur de virtualisation Proxmox, un switch administrable, une borne Wi-Fi et un pare-feu pfSense de test. J'y ai reproduit l'infrastructure d'un client avant toute modification, afin de tester les configurations sans risque. Cette maquette a servi de base au projet présenté dans la partie suivante.
Troisième partie — Projet analysé : découper en VLAN le réseau d'un cabinet de santé
Le constat de départ
Le client est un cabinet regroupant six kinésithérapeutes et ostéopathes, ainsi qu'une secrétaire. Lors d'une visite de maintenance, mon tuteur avait relevé un problème de conception : tout le réseau était à plat. Les postes de travail, le NAS contenant les dossiers des patients, l'imprimante, la télévision de la salle d'attente et le Wi-Fi proposé aux patients partageaient le même réseau. En pratique, un patient connecté au Wi-Fi de la salle d'attente pouvait voir le NAS dans son explorateur réseau. Même protégé par un mot de passe, celui-ci se trouvait ainsi exposé à quiconque s'asseyait sur une chaise du cabinet.
Pour des données de santé, ce n'était pas acceptable. Le gérant du cabinet a accepté un devis de mise en conformité, et mon tuteur m'a confié la préparation du projet sous sa supervision.
La conception
Inventaire. J'ai commencé par recenser tous les équipements, avec leur adresse, leur rôle et le type de données qu'ils manipulent. Cet inventaire a fait apparaître des équipements oubliés : un terminal de paiement relié en Ethernet et une caméra de la porte d'entrée.
Plan d'adressage. J'ai proposé de répartir les équipements en réseaux virtuels (VLAN) selon leur niveau de confiance :
| VLAN | Usage | Réseau | Règle principale |
|---|---|---|---|
| 10 | Postes des praticiens et du secrétariat | 192.168.10.0/24 | Accès au NAS et à internet |
| 20 | NAS et serveurs | 192.168.20.0/24 | Accessible seulement depuis le VLAN 10 |
| 30 | Imprimante, télévision, caméra | 192.168.30.0/24 | Pas d'accès aux autres VLAN, sauf exceptions documentées |
| 40 | Wi-Fi des patients | 192.168.40.0/24 | Internet uniquement, isolation entre clients |
| 99 | Administration des équipements réseau | 192.168.99.0/24 | Réservé aux techniciens |
Matériel. Le switch d'origine n'était pas administrable ; il a fallu le remplacer par un modèle gérant les VLAN (norme 802.1Q). Le routage entre les VLAN et le filtrage sont confiés à un pare-feu pfSense installé sur un petit boîtier dédié, placé derrière la box de l'opérateur. La borne Wi-Fi existante pouvait diffuser deux réseaux distincts : un réseau pour les praticiens (VLAN 10), protégé par une authentification WPA2 avec une clé robuste, et un réseau patients (VLAN 40).
Règles de filtrage. Le principe retenu était celui du moindre privilège : tout est interdit entre les VLAN, puis on autorise uniquement les flux nécessaires. Pour le VLAN des patients, j'ai créé une règle bloquant l'accès à toutes les plages d'adresses privées avant la règle autorisant internet.
Tests en maquette. J'ai reproduit l'ensemble dans le laboratoire, avec des machines virtuelles jouant le rôle des postes, du NAS et d'un téléphone de patient. J'ai vérifié chaque règle en tentant volontairement des connexions interdites : depuis le « téléphone patient », impossible de joindre le NAS ou l'interface d'administration du switch ; depuis un « poste », accès normal au partage de fichiers.
La mise en œuvre
L'intervention a eu lieu un jeudi soir, après la fermeture du cabinet, pour ne pas perturber les consultations. J'avais préparé un plan d'intervention en quatre temps : sauvegarde des configurations existantes et photographie du câblage ; remplacement du switch et installation du pare-feu ; reconfiguration de la borne Wi-Fi et des adresses fixes ; tests poste par poste. Un plan de retour arrière prévoyait de rebrancher l'ancien switch et de revenir à la configuration initiale si le cabinet ne pouvait pas fonctionner normalement le lendemain matin.
L'intervention a duré environ trois heures. J'ai réalisé le brassage et la configuration du switch ; mon tuteur s'est chargé du pare-feu et a contrôlé chacune de mes étapes.
Les imprévus et leur résolution
Deux problèmes sont apparus pendant les tests, et un troisième le lendemain.
- Les patients n'accédaient pas à internet. Le Wi-Fi patients attribuait bien des adresses, mais aucune page ne s'ouvrait. Les appareils recevaient le pare-feu comme serveur DNS, mais ma règle bloquant toutes les plages privées les empêchait justement de le joindre pour la résolution de noms. J'ai ajouté une règle autorisant uniquement le service DNS vers le pare-feu, placée avant la règle de blocage.
- Le scanner de l'imprimante ne déposait plus les fichiers. L'imprimante multifonction, désormais dans le VLAN 30, envoyait ses numérisations vers un dossier partagé du poste de la secrétaire, dans le VLAN 10. J'ai documenté puis créé une exception limitée à ce seul flux, de l'adresse de l'imprimante vers celle du poste.
- Le terminal de paiement ne fonctionnait plus le matin. Nous l'avions placé dans le VLAN 30, mais il nécessitait un accès sortant particulier. La secrétaire a appelé dès l'ouverture ; mon tuteur a corrigé la règle à distance en quelques minutes. Cet oubli venait de mon inventaire : j'avais noté le terminal, mais pas les flux dont il avait besoin.
Regard critique
Le projet a atteint son objectif principal : depuis la salle d'attente, le NAS est désormais invisible. Le client dispose d'un schéma du réseau, d'un tableau des règles de filtrage et d'une fiche simple expliquant à la secrétaire quel réseau Wi-Fi donner aux patients.
Avec le recul, je retiens trois enseignements. D'abord, il aurait fallu établir une matrice des flux avant les règles : pour chaque équipement, avec qui il doit communiquer et sur quel service. Les trois imprévus venaient tous de flux non anticipés. Ensuite, la maquette, si utile soit-elle, ne remplace pas la réalité : aucun de mes tests n'incluait un terminal de paiement. Enfin, la communication compte autant que la technique : prévenir la secrétaire de l'intervention et lui laisser le numéro d'astreinte a permis de résoudre le dernier problème avant le premier rendez-vous.
Si je devais refaire ce projet, je passerais également à WPA3 pour le réseau des praticiens lorsque tous les appareils le permettent, et je proposerais au client une authentification individuelle plutôt qu'une clé partagée.
Quatrième partie — Ce que ces cinq semaines m'ont appris
Compétences mobilisées
Ce stage m'a permis de travailler sur les trois blocs de compétences du BTS SIO :
- Support et mise à disposition de services informatiques : traitement des tickets, gestion du parc dans GLPI, déploiement de postes, rédaction de procédures pour les utilisateurs.
- Administration des systèmes et des réseaux (option SISR) : gestion de l'annuaire Active Directory, configuration de VLAN et d'un pare-feu, supervision et sauvegardes.
- Cybersécurité des services informatiques : cloisonnement d'un réseau contenant des données de santé, vérification d'identité avant réinitialisation de mot de passe, mise en place d'une alerte sur l'absence de sauvegarde.
Plusieurs de ces réalisations, en particulier la maquette et le projet de segmentation, pourront être présentées dans mon portefeuille de compétences, accompagnées de leur documentation.
Difficultés rencontrées
Ma principale difficulté a été de rester calme au téléphone face à un utilisateur pressé, tout en suivant une démarche de diagnostic méthodique. J'avais tendance à proposer une solution avant d'avoir posé toutes les questions. Mon tuteur m'a appris à reformuler le problème avant d'agir. Sur le plan technique, la logique des règles de pare-feu, qui s'appliquent dans un ordre précis, m'a demandé plusieurs essais en laboratoire avant d'être vraiment comprise.
Projet professionnel
Ces semaines ont renforcé mon goût pour les réseaux et la sécurité. Le métier de technicien en infogérance m'a plu par sa variété : en une journée, on peut passer d'une étude notariale à une menuiserie, chacune avec ses contraintes. Je souhaite poursuivre après le BTS vers une licence professionnelle ou un bachelor orienté cybersécurité, de préférence en alternance, pour continuer à apprendre au contact des clients.
Conclusion
Je suis arrivé chez Opalis Infogérance avec des connaissances de cours sur les VLAN, l'annuaire et les sauvegardes ; j'en repars avec l'expérience de leurs conséquences concrètes. Une alerte ajoutée à la supervision peut éviter la perte de semaines de travail ; une règle de pare-feu mal ordonnée peut bloquer le paiement des patients d'un cabinet. Le projet de segmentation m'a montré qu'une bonne solution technique repose d'abord sur une bonne connaissance de l'existant et sur un dialogue clair avec le client. Ce sont ces deux points que je veux travailler en deuxième année, en commençant mes prochains projets par l'inventaire des flux plutôt que par la configuration.
Remerciements
Je remercie le dirigeant d'Opalis Infogérance de m'avoir accueilli dans son entreprise, ainsi que M. R., mon tuteur, pour sa patience et pour m'avoir laissé une vraie responsabilité sur le projet du cabinet. Merci également aux techniciens du support, qui m'ont fait une place dans leur bureau et ont relu mes premiers tickets, et à la secrétaire du cabinet de kinésithérapie pour sa disponibilité. Je remercie enfin l'équipe pédagogique de ma section pour son accompagnement dans la recherche de ce stage.
Annexes
- Annexe 1 : organigramme simplifié d'Opalis Infogérance
- Annexe 2 : exemple de ticket GLPI avant et après réécriture
- Annexe 3 : liste de contrôle pour la livraison d'un poste de travail
- Annexe 4 : schéma du réseau du cabinet avant et après segmentation
- Annexe 5 : plan d'adressage et tableau des règles de filtrage pfSense
- Annexe 6 : plan d'intervention et plan de retour arrière
- Annexe 7 : fiche d'utilisation du Wi-Fi remise au secrétariat