L'arrêté du 26 avril 2011 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 (B.O. n° 22 du 2 juin 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 2013 et 2014.

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 composé d'une organisation cliente et d'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.).
1.2 Les besoins de l'organisation cliente en matière de création ou d'amélioration de services informatiques 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 (type smartphone, tablette, ou encore assistant personnel).
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 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, 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 des 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 ;
- 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.