Edité par le M.E.S.R.I. le bulletin officiel de l'Enseignement supérieur, de la Recherche et de l'Innovation porte sur l'actualité des textes réglementaires : décrets, circulaires, arrêtés, notes de service, avis de vacances de postes, etc. Il édite également des numéros spéciaux et hors série.

Brevet de technicien supérieur

Cahier des charges concernant l'épreuve E4 conception et maintenance de solutions informatiques du BTS services informatiques et organisation pour les sessions d'examen 2019 et 2020

NOR : ESRS1801459N
note de service n° 2018-016 du 25-1-2018
MEN - MESRI - DGESIP A1-2


Texte adressé aux rectrices et recteurs d’académie, chancelières et chanceliers des universités ; aux vice-rectrices et vice-recteurs ; aux inspectrices et inspecteurs d’académie-inspectrices et inspecteurs pédagogiques régionaux ; aux directrices et directeurs académiques des services de l’éducation nationale ; au directeur du Cned ; au directeur du Siec d’Île-de-France ; aux cheffes et chefs d’établissement

L'arrêté du 26 avril 2011 modifié portant définition et fixant les conditions de délivrance du brevet de technicien supérieur Services informatiques aux organisations, paru au Journal officiel de la République française le 17 mai 2011, prévoit dans la définition de l'épreuve E4 conception et maintenance de solutions informatiques, le respect de contextes définis dans un cahier des charges national.

La présente note reconduit le cahier des charges défini dans la note de service n° 2017-012 du 19 janvier 2017 publiée au Bulletin officiel n° 7 du 16 février 2017 pour les sessions 2019 et 2020.

Règles de constitution des contextes

1. Règles communes aux deux parcours Solutions d'infrastructure, systèmes et réseaux(SISR) et Solutions logicielles et applications métiers (Slam)
1.1 Un contexte est un environnement d'apprentissage dans lequel une organisation cliente adresse une demande à un prestataire informatique interne ou externe à l'organisation cliente. Ces organisations sont réelles ou directement inspirées du réel. L'organisation cliente et le prestataire informatique sont décrits à travers leurs principaux processus métier et support, leur système d'information et l'ensemble de leurs relations formalisées (contrats ou catalogue de services, politique de sécurité, charte, etc.). La demande peut porter sur l'évolution ou la maintenance d'un ou plusieurs éléments de l'environnement technologique d'apprentissage et les réponses apportées peuvent mobiliser d'autres solutions techniques (par exemple, en Slam recours à un outil de développement exploité pour faire évoluer une solution logicielle et en SISR utilisation d'un outil de gestion de configuration pour enregistrer une évolution de l'infrastructure de communication).
1.2 Les besoins de l'organisation cliente sont clairement identifiés dans un ou plusieurs cahiers des charges qui définissent les contraintes techniques, financières et temporelles à respecter.
1.3 L'environnement technologique d'apprentissage supportant le système d'information de l'organisation cliente comporte au moins :
- un service d'authentification pour les utilisateurs internes et externes à l'organisation ;
- un SGBD ;
- un accès sécurisé à Internet ;
- un environnement de travail collaboratif ;
- un logiciel de gestion d'incidents ;
- un logiciel de gestion des configurations ;
- deux serveurs, éventuellement virtualisés, basés sur des systèmes d'exploitation différents, dont l'un est un logiciel open source ;
- une solution de sauvegarde ;
- des ressources dont l'accès est sécurisé et soumis à habilitation ;
- deux types de solution technique d'accès dont une mobile (par exemple un smartphone, une tablette).
1.4 Les logiciels de simulation ou d'émulation sont utilisés en réponse à des besoins de l'organisation. Ils ne peuvent se substituer à des équipements réels dans l'environnement technologique d'apprentissage. Une solution d'infrastructure réduite à une simulation par un logiciel ne peut être acceptée.
1.5 Tous les documents et ressources qui décrivent un contexte doivent être accessibles en ligne via Internet aux commissions de correction à partir d'une date fixée par les autorités académiques :
- documents de présentation des organisations (organisation cliente et prestataire informatique) ;
- description de l'environnement technologique d'apprentissage ;
- tout ou partie des documents de référence utilisés par l'organisation cliente et par le prestataire informatique qui sont utiles pour définir le contexte (référentiels de bonnes pratiques, normes ou standards, description des processus, données métiers, etc.) et nécessaires pour le déroulement de l'épreuve ;
- les schémas d'infrastructure réseau ;
- la documentation technique des services disponibles ;
- les fichiers de configuration, la documentation technique des équipements matériels et logiciels disponibles ;
- les éléments financiers et juridiques liés aux services et aux équipements disponibles.
1.6 Lorsque les deux situations professionnelles présentées par un candidat s'appuient sur deux contextes différents, chaque contexte et son environnement technologique d'apprentissage doivent respecter les règles communes aux deux parcours. Le respect des règles relatives au parcours du candidat (SISR ou Slam) est mesuré à partir du cumul des caractéristiques des deux environnements technologiques d'apprentissage.
2. Règles spécifiques au parcours SISR
2.1 L'environnement technologique supportant le système d‘information de l'organisation cliente comporte au moins :
- un réseau comportant plusieurs périmètres de sécurité ;
- une solution permettant l'administration à distance sécurisée de serveurs et de solutions techniques d'accès ;
- un logiciel d'analyse de trames ;
- un logiciel de supervision système et réseau ;
- trois types de solution technique d'accès dont une mobile (par exemple un smartphone, une tablette) ;
- un service rendu à l'utilisateur final respectant un contrat de service comportant des contraintes en termes de sécurité et de haute disponibilité.
2.2 La structure et les activités de l'organisation s'appuient sur au moins trois solutions d'infrastructures opérationnelles parmi les suivantes :
2.2.1 une solution garantissant des accès sécurisés à un service, internes au périmètre de sécurité de l'organisation (type intranet) ou externes (type Internet ou extranet) ;
2.2.2 une solution garantissant la continuité d'un service ;

2.2.3 une solution garantissant la tolérance de panne de systèmes serveurs ou d'éléments d'interconnexion ;
2.2.4 une solution permettant la connexion sécurisée entre deux sites distants ;
2.2.5 une solution permettant le déploiement des solutions techniques d'accès ;
2.2.6 une solution gérée à l'aide de procédures automatisées écrites avec un langage de scripting ;
2.2.7 une solution permettant la supervision de la qualité, de la sécurité et de la disponibilité des services avec remontées d'alertes ;
2.2.8 une solution permettant la détection d'intrusions ou de comportements anormaux sur le réseau ;
2.2.9 une solution permettant la répartition de charges entre services, serveurs ou éléments d'interconnexion.
2.3 Les solutions d'infrastructure présentes dans le contexte sont opérationnelles et documentées. Elles s'appuient sur des composants matériels accessibles au moment de l'épreuve.
3. Règles spécifiques au parcours Slam 
3.1 L'environnement technologique supportant le système d‘information de l'organisation cliente comporte au moins :
- un ou deux environnements de développement disposant d'outils de gestion de tests et supportant un framework et au moins deux langages ;
- une bibliothèque de composants logiciels ;
- un SGBD avec langage de programmation associé ;
- un logiciel de gestion de versions.
3.2 Les activités de l'organisation cliente s'appuient sur aux moins deux solutions applicatives opérationnelles permettant d'offrir un accès sécurisé à des données hébergées sur un site distant. Au sein des architectures de ces solutions applicatives doivent figurer l'exploitation de mécanismes d'appel à des services applicatifs distants et au moins trois des situations ci-dessous :
3.2.1 du code exécuté sur le système d'exploitation d'une solution technique d'accès fixe (type client lourd) ;
3.2.2 du code exécuté dans un navigateur web (type client léger ou riche, applet, etc.) ;
3.2.3 du code exécuté sur le système d'exploitation d'une solution technique d'accès mobile ;
3.2.4 du code exécuté sur le système d'exploitation d'un serveur (servlet, procédure cataloguée, etc.).
3.3 Une solution applicative peut être issue d'un développement spécifique ou de la modification du code d'un logiciel (open source par exemple).
3.4 Les solutions applicatives présentes dans le contexte sont opérationnelles et leur code source est accessible dans un environnement de développement opérationnel au moment de l'épreuve.


Pour la ministre de l'Enseignement supérieur, de la Recherche et de l'Innovation et par délégation,
Pour la directrice générale de l'enseignement supérieur et de l'insertion professionnelle,
La cheffe de service de la stratégie des formations et de la vie étudiante,
Rachel-Marie Pradeilles-Duval

Abonnement

Abonnez-vous à l'alerte courriel 
pour recevoir chaque semaine le sommaire du B.O.  :

S'abonner au sommaire

Se désabonner

 

Mentor

Recherche de textes réglementaires parus au B.O. et au J.O.  du M.E.N.E.S.R.

Mentor vous permet de consulter :

  • les références des textes parus au B.O. ou au J.O. après 1987
  • l'intégralité  des textes s'ils sont postérieurs à juillet 1989 pour le B.O. et à juillet 2003 pour le J.O.

Le moteur de recherche Mentor

Retour haut de page

Les recherches les plus fréquentes :