Titre pro CDA

Comment se préparer

Ce que dit le référentiel, sans le jargon : comment se déroule l’épreuve, ce qu’il faut rendre, ce que le jury regarde, et les pièges à éviter.

Le déroulé

2 h 15 d’épreuve, en quatre temps.

Avant la présentationQuestionnaire professionnel30 min
- Tous les candidats en même temps, avec un surveillant.
- Sur un poste sans internet, téléphones interdits.
- Vous étudiez une documentation technique en anglais.
- Deux questions fermées à choix unique, en français.
- Deux questions ouvertes en anglais, réponses courtes rédigées en anglais.
Le cœur de l’épreuvePrésentation du projet40 min
- Le jury a lu votre dossier de projet imprimé avant de vous voir.
- Vous présentez avec votre diaporama, préparé en amont.
- Le jury écoute sans intervenir.
Juste après la présentationEntretien technique45 min
- Questions sur votre dossier de projet et votre présentation.
- Puis sur les compétences que votre projet ne couvre pas.
Pour finirEntretien final20 min
- Un échange avec le jury, qui a votre dossier professionnel sous les yeux.
- Il vérifie votre vision globale du métier et de sa culture professionnelle.

135 minutes au total pour vous. Le jury, lui, a lu votre dossier avant même que vous n’entriez.

Ce qu’il faut rendre

Ce que vous rendez avant l’épreuve.

40–60pagesLe dossier de projetUn seul, imprimé, qui réunit tous vos projets. Hors page de garde, sommaire et annexes, schémas et illustrations compris.
≤ 40pagesLes annexesLes éléments de la fonctionnalité la plus représentative : maquettes, captures d’écran et leur code, code métier, d’accès aux données…
1DPLe dossier professionnelLe document officiel où vous décrivez des exemples concrets de votre pratique pour chaque activité du titre. Le jury l’évalue, et l’a en main pendant l’entretien final.
1diaporamaLe support de présentationUn seul diaporama pour l’ensemble des projets, réalisé avant l’épreuve.

Vous passez un CCP seul (« Développer une application sécurisée ») ? Le dossier fait alors 30 à 40 pages, annexes 20 pages maximum.

Les compétences obligatoires

Ce que votre projet doit couvrir.

Les intitulés du référentiel sont abstraits. Voici ce qu’ils veulent dire, et ce que vous pouvez montrer pour chacun.

Activité 1Développer une application sécurisée

Développer des interfaces utilisateur
En clairCoder les écrans de l’application, ce que l’utilisateur voit et manipule, à partir de vos maquettes.
À montrerDes écrans conformes aux maquettes, qui s’adaptent au support, avec leur code et quelques tests.
Développer des composants métier
En clairCoder la logique de l’application : les règles propres au domaine. Par exemple « un lecteur ne peut pas emprunter plus de 5 livres ». C’est souvent côté serveur, dans des services.
À montrerUn service ou une classe qui applique une vraie règle de gestion, sécurisé et testé.
Contribuer à la gestion d’un projet informatique
En clairOrganiser le travail : découper en tâches, planifier, suivre l’avancement, choisir les outils de l’équipe.
À montrerVotre board (Jira, Trello…), une user story, votre planning, votre workflow Git.

Activité 2Concevoir et développer une application sécurisée organisée en couches

Analyser les besoins et maquetter une application
En clairComprendre ce que veut le client, puis le traduire en écrans avant de coder.
À montrerL’expression des besoins, le zoning, le wireframe, la maquette, et le schéma d’enchaînement des écrans.
Définir l’architecture logicielle d’une application
En clairDécider comment l’application est découpée : quelles couches (interface, métier, données), quels services, quels frameworks, et comment ils communiquent.
À montrerUn schéma d’architecture en couches, avec le rôle de chacune et le pourquoi de vos choix.
Concevoir et mettre en place une base de données relationnelle
En clairModéliser les données (MCD, MLD) puis créer la vraie base, avec ses contraintes et ses droits d’accès.
À montrerVos schémas MERISE, le script SQL de création, et une base de test avec un jeu d’essai.
Développer des composants d’accès aux données SQL et NoSQL
En clairCoder la partie qui lit et écrit dans la base : requêtes, ORM, repositories, en contrôlant les entrées et en gérant les erreurs.
À montrerLe code d’accès aux données (requêtes, repository, ORM) et la façon dont vous protégez les entrées.

Activité 3Préparer le déploiement d’une application sécurisée

Préparer et exécuter les plans de tests d’une application
En clairPrévoir ce qu’il faut tester et comment, l’exécuter, puis comparer le résultat obtenu au résultat attendu.
À montrerVotre plan de tests, quelques tests automatisés, et le jeu d’essai de votre fonctionnalité principale.
Préparer et documenter le déploiement d’une applicationÉvaluée à l’entretien technique
En clairÉcrire comment on met l’application en ligne : la procédure, les scripts, les environnements (test, production), pour que quelqu’un d’autre puisse le refaire.
À montrerVotre procédure de déploiement, vos scripts commentés (Dockerfile, docker-compose…) et vos environnements.
Contribuer à la mise en production dans une démarche DevOpsÉvaluée à l’entretien technique
En clairAutomatiser le chemin du code jusqu’à la production : intégration continue, tests et outils de qualité lancés automatiquement, déploiement.
À montrerVotre pipeline CI/CD (GitHub Actions, GitLab CI…), ses étapes, et comment vous lisez ses rapports.

Les compétences marquées « entretien technique » n’ont pas à figurer dans votre projet : le jury les évalue pendant l’entretien. L’installation de votre environnement de travail est aussi évaluée à l’entretien et au questionnaire.

Le dossier de projet

Le plan attendu, dans l’ordre.

01La liste des compétences mises en œuvre
02Le cahier des charges ou l’expression des besoins
03La présentation de l’entreprise et du service
04La gestion de projet : planning et suivi, environnement humain, objectifs de qualité
05Les spécifications fonctionnelles : contraintes et livrables, architecture logicielle, maquettes et leur enchaînement, modèle entités-associations et modèle physique, script de création de la base, diagramme de cas d’utilisation, diagramme de séquence des cas les plus significatifs
06Les spécifications techniques, sécurité comprise
07Vos réalisations : les extraits de code les plus significatifs (interfaces, composants métier, accès aux données, contrôleurs…) et les arguments de vos choix
08Les éléments de sécurité de l’application
09Le plan de tests
10Le jeu d’essai de la fonctionnalité la plus représentative : données en entrée, attendues, obtenues, et l’analyse des écarts
11La veille sur les vulnérabilités de sécurité : ce que vous avez trouvé et corrigé

Projet réalisé pendant la formation : le plan est plus court. Les compétences mises en œuvre, l’expression des besoins (objectifs et limites du projet), l’environnement technique, et les réalisations qui démontrent les compétences.

Les intentions du jury

Ce qu’il regarde.

Il vous lit avant de vous voirVotre dossier imprimé est sa première impression. Soignez-le comme votre présentation.
Il vous laisse parler40 minutes sans interruption : c’est à vous de structurer et de tenir le temps.
Puis il creuse45 minutes pour vérifier que vous maîtrisez ce que vous avez montré, et vous interroger sur ce que votre projet ne couvre pas.

Quelques critères de la grille d’évaluation

Interfaces & conception

L’interface est conforme au dossier de conception
Elle s’adapte au support (taille, type, disposition)
La charte graphique et la réglementation sont respectées
L’enchaînement des maquettes est formalisé par un schéma
Les besoins d’éco-conception sont identifiés

Architecture & données

L’architecture multicouche est sécurisée, le rôle de chaque couche est défini
Le schéma conceptuel respecte les règles du relationnel
L’intégrité, la sécurité et la confidentialité des données sont assurées
Une base de test existe, avec un jeu d’essai complet, restaurable
Toutes les entrées sont contrôlées et validées côté serveur

Tests & déploiement

Le plan de tests couvre toutes les fonctionnalités retenues
Les résultats obtenus sont cohérents avec les résultats attendus
Des tests unitaires et de sécurité accompagnent les composants
La procédure de déploiement est rédigée, les scripts documentés
Les scripts d’intégration continue s’exécutent sans erreur

À ne surtout pas faire

Les erreurs fréquentes.

Dépasser les 60 pages ou les 40 minutes.
Oublier une compétence obligatoire dans vos projets.
Montrer du code que vous ne savez pas expliquer ligne par ligne.
Ne sécuriser que le front : cacher un bouton ne protège pas une route.
Arriver sans plan de tests ni jeu d’essai.
Improviser la démo.
Lire vos slides, ou réciter votre dossier.
Négliger l’anglais : le questionnaire et une partie de la documentation sont en anglais.
Reprendre le dossier d’un autre sans l’adapter.

L’IA

Utiliser l’IA pour se préparer.

Le jury évalue votre maîtrise de ce que vous présentez, pendant 40 minutes de présentation puis 45 minutes d’entretien technique. L’IA peut vous aider à vous préparer, à condition de savoir expliquer tout ce que vous rendez.

Oui

Lui demander de vous expliquer un concept, puis le reformuler avec vos mots.
Vous faire interroger : « Pose-moi des questions de jury sur mon MCD ».
Faire relire un passage pour la clarté, après l’avoir écrit vous-même.
Vérifier chaque affirmation dans la doc officielle.

Non

Faire écrire votre dossier : un texte généré reste générique et ne décrit pas vos choix.
Présenter du code généré que vous ne savez pas défendre.
Croire ce qu’elle affirme sans vérifier : elle invente des librairies, des normes, des chiffres.
Compter sur elle le jour J : le questionnaire se passe sans internet.

Biais cognitif

Le biais de confirmation, côté jury.

Le biais de confirmation, c’est la tendance à chercher ce qui confirme une première impression. Or le jury lit votre dossier avant de vous rencontrer : s’il a le sentiment, dès les premières pages, d’un projet entièrement généré par l’IA, cette impression peut orienter toute la suite de l’épreuve.

Elle se forme tôtLe dossier imprimé est lu avant votre présentation. C’est lui qui installe la première image de vous, avant même que vous ayez parlé.
Elle oriente la suiteUne fois l’idée installée, une hésitation, une formulation vague ou une ligne de code mal expliquée sont lues comme des confirmations. Les questions de l’entretien vont chercher à vérifier.
Elle joue aussi dans l’autre sensUn dossier qui montre vos choix, vos arbitrages et vos difficultés installe d’emblée l’image d’un candidat qui maîtrise son projet.

Ce qui peut donner cette impression, et ce qui montre votre travail

Impression « généré »Des paragraphes génériques qui pourraient décrire n’importe quelle application.Votre travailDes phrases sur votre projet : vos contraintes, vos choix, ce que vous avez écarté et pourquoi.
Impression « généré »Du code que vous avez du mal à expliquer, des commentaires qui paraphrasent le code.Votre travailDu code que vous savez commenter ligne par ligne, avec vos conventions.
Impression « généré »Aucune difficulté, aucun retour en arrière : tout a marché du premier coup.Votre travailLes vrais obstacles rencontrés, et comment vous les avez résolus.
Impression « généré »Des maquettes et une interface sans lien entre elles.Votre travailUne démarche visible : du zoning à la maquette, puis à l’écran réel.

Le jour J

Les derniers conseils.

01
Le support est une synthèse du dossier projet, pas une copie : couvrez les compétences du référentiel et tenez le temps.
02
Le projet n’est jugé ni sur l’innovation, ni sur le nombre de fonctionnalités.
03
La démo est scénarisée et répétée. Jamais improvisée.
04
Le jury peut vous demander de commenter une ligne de code dans votre IDE : connaissez votre code.
05
Il peut aussi naviguer dans l’application, par exemple pour vérifier une route protégée.
06
Plusieurs solutions sont toujours possibles : ce qui compte, c’est de savoir justifier les vôtres.
07
Répétez à voix haute, chronomètre en main. Plusieurs fois.

Source : Référentiel d’évaluation du titre CDA (TP-01281), version du 13/05/2023.