bo Le Bulletin officiel de l'éducation nationale, de la jeunesse et des sports

Le Bulletin officiel de l'éducation nationale, de la jeunesse et des sports publie des actes administratifs : décrets, arrêtés, notes de service, etc. La mise en place de mesures ministérielles et les opérations annuelles de gestion font l'objet de textes réglementaires publiés dans des BO spéciaux.

Enseignements secondaire et supérieur

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 2017 et 2018

NOR : MENS1701374N

Note de service n° 2017-012 du 19-1-2017

MENESR - 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 centre national d'enseignement à distance ; au directeur du service interacadémique des examens et concours ; aux 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 a pour objet de définir les règles de constitution des contextes supports de cette épreuve pour les sessions 2017 et 2018.

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 exemples, en SLAM recours à 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 exemples 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 exemples 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'éducation nationale, de l'enseignement supérieur et de la recherche
et par délégation,
La directrice générale de l'enseignement supérieur et de l'insertion professionnelle,
Simone Bonnafous