Ce décalage entre l’image de la certification et ce qu’elle teste réellement sur son examen le plus difficile explique une bonne partie des échecs évitables. Réviser le A+ comme on réviserait « un examen de matériel » revient à sous-investir la moitié du score de Core 2.

Le piège : réviser le hardware et négliger l’OS/sécurité

La confusion est logique. Le nom « A+ » et son image publique (formation IT d’entrée de gamme, cours de « montage PC ») orientent naturellement la préparation vers le matériel : composants, connecteurs, périphériques, dépannage physique. C’est exactement ce que couvre Core 1. Le problème, c’est que Core 1 et Core 2 sont deux examens séparés, avec deux seuils de réussite différents, et que rien dans le nom de la certification n’indique lequel des deux est le plus exigeant.

Le hardware ne réapparaît nulle part dans la pondération de Core 2. Et Core 2 n’est pas l’examen « bonus » ou secondaire — c’est celui avec le seuil de réussite le plus élevé (700/900 contre 675/900) et celui que praticiens et organismes de formation décrivent de façon quasi unanime comme le plus difficile des deux, précisément à cause de son volume de raisonnement par scénario en OS et sécurité plutôt que de rappel factuel sur des composants.

Pourquoi Core 2 est considéré plus dur que Core 1

Le hardware se révise bien avec de la mémorisation : un connecteur a une forme, un type de RAM a des broches, un port a un débit. C’est vérifiable, binaire, peu ambigu. Les systèmes d’exploitation et la sécurité fonctionnent différemment sur cet examen : les questions sont majoritairement des mises en situation (« un utilisateur signale X, quelle est la première étape de dépannage ? ») où plusieurs réponses semblent plausibles et où seule la compréhension du raisonnement — pas la mémorisation d’un fait isolé — permet de trancher.

La mise à jour 2025 (retrait des anciens 220-1101/1102 le 25 septembre 2025, remplacés par les 220-1201/1202 depuis mars 2025) a accentué cet écart plutôt que de le réduire. Environ 87 % du contenu de Core 1 reste inchangé par rapport à la version précédente — c’est une mise à jour, pas une refonte. Mais les ajouts qui existent vont tous dans le même sens sur Core 2 : renforcement de la sécurité (dont les principes Zero Trust), approfondissement de Windows 11, nouveaux systèmes de fichiers (ReFS, XFS) et un premier passage sur les enjeux liés à l’IA côté confidentialité. Rien de tout ça n’allège la charge de mémorisation hardware de Core 1 — ça alourdit celle, plus exigeante en raisonnement, de Core 2.

3 questions type Core 2 — et pourquoi le réflexe « hardware » ne sert à rien ici

Question 1 — Domaine Systèmes d’exploitation (28 %)
Un technicien doit vérifier si le TPM (Trusted Platform Module) est activé sur un poste avant une mise à niveau vers Windows 11. Quelle commande utiliser ?
A) diskpart
B) tpm.msc
C) msconfig
D) gpupdate

La bonne réponse est B. Rien ici ne teste une connaissance de composant physique — c’est une question sur un prérequis logiciel de Windows 11 (le TPM 2.0 est obligatoire depuis son lancement) et sur l’outil natif pour le vérifier. Un candidat qui a révisé les caractéristiques matérielles des cartes mères mais pas les outils d’administration Windows 11 bute ici.

Question 2 — Domaine Sécurité (28 %)
Une entreprise migre vers un modèle où chaque requête d’accès est vérifiée individuellement, sans confiance implicite accordée au réseau interne. Quel principe cela illustre-t-il ?
A) Défense en profondeur
B) Zero Trust
C) Moindre privilège
D) Séparation des tâches

La bonne réponse est B. Le piège classique consiste à confondre Zero Trust avec le principe de moindre privilège (réponse C) : le moindre privilège limite ce qu’un utilisateur peut faire une fois authentifié, Zero Trust remet en cause la confiance accordée par défaut à chaque requête, y compris depuis l’intérieur du réseau. C’est une distinction conceptuelle, pas une question de connaître un composant.

Question 3 — Domaine Dépannage logiciel (23 %)
Une application Windows se lance mais se ferme immédiatement sans message d’erreur. Quelle est la première étape de dépannage la plus appropriée ?
A) Réinstaller Windows
B) Vérifier les journaux d’événements (Event Viewer)
C) Remplacer le disque dur
D) Désactiver le pare-feu

La bonne réponse est B. C’est le type de question qui piège les candidats venus du hardware : face à un problème, le réflexe « matériel » pousse vers des solutions physiques ou radicales (A, C). Core 2 teste une méthodologie de diagnostic logiciel progressive — commencer par la source d’information la moins destructive avant d’envisager des actions plus lourdes.

Ce que ça change concrètement pour la répartition du temps de révision

Le A+ complet (Core 1 + Core 2) reste une certification d’entrée de gamme accessible, mais elle n’est plus — si elle l’a jamais vraiment été — un simple examen de reconnaissance de composants. Le déséquilibre le plus fréquent chez les candidats qui échouent au A+ n’est pas un manque de préparation globale, c’est une préparation mal répartie : beaucoup de temps passé sur le hardware de Core 1, pas assez sur le raisonnement par scénario de Core 2.

Concrètement, sur un plan de révision de 6 semaines pour les deux examens, ça veut dire ne pas répartir le temps 50/50 par défaut entre Core 1 et Core 2 sous prétexte que ce sont « deux examens équivalents ». Core 2 mérite structurellement plus de temps de mise en situation (cas pratiques de dépannage, scénarios de sécurité) et moins de pur par-cœur — l’inverse de ce que la réputation « hardware » du A+ pousse instinctivement à faire.

Sources

• CompTIA — A+ Core 1 and 2 (V15), pondérations officielles et positionnement de la certification
• StationX — 2025 CompTIA A+ Update: 220-1101/1102 vs 220-1201/1202
• CBT Nuggets — CompTIA A+ Exam Update: What’s Changing in 2025

L’article CompTIA A+ : pourquoi Core 2 n’a presque rien à voir avec le hardware (et coûte plus de points que Core 1) est apparu en premier sur MyExam.fr.

Le problème, c’est que je n’ai trouvé aucune trace d’un organisme certifiant qui ait réellement publié ces chiffres. J’ai vérifié quatre certifications IT majeures — testing logiciel, cloud, gestion de projet, cybersécurité — représentant quatre organismes totalement indépendants. Le résultat est le même à chaque fois : aucun ne communique de taux de réussite officiel par examen. Et pourtant, l’écosystème de sites qui vendent des formations et des dumps continue d’en publier, avec deux décimales de précision, comme si c’était une donnée vérifiée.

ISTQB : le seul chiffre « officiel » est un calcul de coin de table

L’ASTQB (le board américain affilié à l’ISTQB) est étonnamment honnête sur le sujet dans sa propre documentation. Elle indique qu’en mai 2025, l’ISTQB avait administré 1,4 million d’examens pour un peu plus d’1 million de certifications délivrées dans le monde. En divisant ces deux totaux, on obtient environ 71 %. C’est d’ailleurs le même flou statistique qu’on retrouve quand on essaie de comparer le Foundation Level et les certifications Advanced comme le CTAL-TM — aucun chiffre officiel ne sépare vraiment les deux niveaux.

Mais l’ASTQB précise elle-même la limite de ce calcul : « This is not an exact published pass rate for every ISTQB exam. It is an estimate based on overall worldwide totals. » Ce n’est pas un taux de réussite par examen — c’est un ratio global toutes certifications confondues, mélangeant le Foundation Level (l’entrée de gamme, relativement accessible) avec les niveaux Advanced, Specialist et Expert (nettement plus sélectifs). Autrement dit, le seul chiffre qui a une trace officielle n’est même pas la statistique que tout le monde utilise pour parler du CTFL spécifiquement.

AWS : la FAQ officielle dit noir sur blanc qu’elle ne communique rien

Sur AWS, il n’y a même pas besoin de faire un calcul indirect — la FAQ Certification officielle tranche la question directement : « AWS Certification passing scores are set by using statistical analysis and are subject to change. AWS does not publish exam passing scores. »

Le fameux « 700/1000 » qu’on trouve partout comme seuil de passage du Cloud Practitioner n’est pas le seuil réel communiqué par AWS — c’est une convention adoptée par les plateformes de préparation, reprise en boucle, qui ignore le fait que le seuil réel varie d’une version d’examen à l’autre (ancrage psychométrique, une technique standard pour comparer équitablement des candidats qui n’ont pas eu exactement les mêmes questions). Il n’y a tout simplement pas de score fixe universel, et encore moins un taux de réussite public. On voit une variante du même problème sur les certifications AWS liées à l’IA, où la confusion entre fine-tuning, RAG et prompt engineering coûte plus de points que la difficulté brute du barème.

PMP et Security+ : même silence, mêmes raisons invoquées

Le PMI n’a plus communiqué de taux de réussite officiel pour le PMP depuis 2005. Le score de passage exact est confidentiel, et pour cause : le PMP utilise un scoring psychométrique dynamique où chaque candidat reçoit un jeu de questions différent, calibré en difficulté. Publier un pourcentage de réussite unique n’aurait statistiquement pas beaucoup de sens — mais ça n’empêche pas des dizaines de sites d’afficher « 61 % » comme si c’était un fait établi par le PMI lui-même.

CompTIA tient la même position sur Security+, mais l’assume de façon plus explicite encore : l’entreprise ne publie pas ses taux de réussite précisément pour éviter que les candidats ne sous-estiment la préparation nécessaire ou ne s’appuient sur un chiffre pour calibrer leurs efforts à la baisse. Les chiffres qui circulent (« 50-65 % en autoformation », « jusqu’à 93 % en bootcamp ») viennent d’agrégats communiqués par… des organismes de formation. Ce sont les mêmes acteurs qui vendent le programme censé faire grimper ce pourcentage. Le conflit d’intérêt n’est même pas caché, juste rarement souligné — le même écosystème de chiffres invérifiables existe autour du domaine Menaces, vulnérabilités et mitigations du SY0-701, présenté comme « le plus difficile » sur la foi d’aucune donnée CompTIA publique.

Pourquoi ce vide se remplit toujours de la même façon

Ce qui m’a frappé en croisant ces quatre cas, ce n’est pas qu’un organisme protège ses données — c’est que la logique est identique partout, malgré des secteurs et des méthodes de scoring complètement différents :

• Empêcher le teaching to the test : si le seuil exact et le taux de réussite étaient publics, les organismes de formation optimiseraient leurs cursus pour « juste passer la barre » plutôt que pour la maîtrise réelle du référentiel.
• Protéger la valeur perçue de la certification auprès des employeurs — un taux de réussite trop haut fait passer la certif pour un tampon, trop bas la fait passer pour inaccessible et décourage les candidats.
• Éviter que les candidats calibrent leur préparation sur un pourcentage plutôt que sur le contenu réel du blueprint.

Le vide statistique laissé par ce silence volontaire est comblé par un écosystème de sites qui ont, eux, un intérêt commercial direct à afficher un chiffre — n’importe lequel, du moment qu’il a l’air précis. Un pourcentage à deux décimales inspire confiance, même sans source primaire derrière. Et une fois qu’un chiffre a été repris par assez de sites, il devient difficile à distinguer d’une vraie statistique : personne ne cite plus l’organisme certifiant, tout le monde cite le site d’à côté qui l’a lui-même recopié.

Ce que ça change pour votre préparation

Concrètement, un « taux de réussite 71 % » ou « 61 % » trouvé en ligne ne devrait jamais entrer dans votre décision de vous sentir prêt ou pas. Ce n’est ni un objectif à battre, ni une jauge d’anxiété légitime — c’est, dans la plupart des cas, un nombre sans source vérifiable qui a simplement survécu assez longtemps sur internet pour paraître officiel.

Ce qui reste, en revanche, solide et vérifiable : le référentiel officiel (syllabus, exam guide, blueprint), le nombre de questions à réussir quand il est publié, et le volume réel d’entraînement sur des questions représentatives du format d’examen. C’est une base bien plus fiable pour juger de sa préparation qu’un pourcentage impossible à tracer jusqu’à sa source.

L’article Le « taux de réussite » des certifications IT : personne ne le publie, tout le monde le cite est apparu en premier sur MyExam.fr.

Ce que dit vraiment le marché de l’emploi, chiffres à l’appui

J’ai regardé les données d’itjobswatch.co.uk, un tracker britannique qui agrège les offres d’emploi permanentes et en extrait des statistiques par mot-clé — un des rares outils à publier des séries chiffrées sur les certifications plutôt que des impressions. Sur les six mois précédant août 2026, 583 postes permanents au Royaume-Uni citent explicitement « AWS Certification ». Le nombre de postes a reculé de 47 places au classement général des compétences sur un an, et surtout : le salaire médian associé à ces offres est tombé à 55 000 £, en baisse de 21,4 % sur la même période.

Vingt et un pourcent en un an, ce n’est pas du bruit statistique. Mais avant d’y voir une preuve que « AWS perd de la valeur », j’ai regardé le détail : sur ces 583 offres, quelle certification AWS domine ? La réponse recadre tout le sujet.

Solutions Architect reste devant Cloud Practitioner dans les offres qui citent une certification AWS précise — et l’écart de salaire entre les deux univers est sans appel. Le salaire médian pour un poste « AWS Solutions Architect » au UK tourne autour de 95 000 £ (jusqu’à 100 000 £ à Londres), contre 55 000 £ pour le salaire médian associé à « AWS Certification » toutes certifs confondues, tirées vers le bas par le poids du Cloud Practitioner dans l’échantillon. Un écart de 73 %. Ce n’est pas une nuance, c’est deux marchés différents qui portent le même logo AWS.

Pourquoi le Cloud Practitioner perd du terrain sans disparaître

Le Cloud Practitioner (CLF-C02) n’est pas une mauvaise certification — c’est une certification qui a rempli son rôle : faire connaître AWS au plus grand nombre. Le problème, c’est que ce succès s’est retourné contre sa valeur signal. Le rapport Skillsoft 2026 IT Skills and Salary Survey note que 93 % des professionnels IT interrogés détiennent désormais au moins une certification, contre environ 87 % un an plus tôt. Quand presque tout le monde a une certification d’entrée, avoir uniquement cette certification-là cesse de différencier un candidat — le signal se dilue mécaniquement à mesure que le nombre de détenteurs augmente, indépendamment de la qualité de la certification elle-même.

C’est exactement ce que confirment les retours de terrain que j’ai croisés sur Blind et dans les threads techniques : le consensus chez les professionnels déjà en poste est que le Cloud Practitioner « est une certification superficielle, pensée pour du non-technique ou pour découvrir AWS », et que quiconque vise un poste technique doit rapidement progresser vers une certification Associate — Solutions Architect, Developer ou Security. Le Cloud Practitioner n’est pas décrié en soi. Il est perçu comme un point de passage, pas une destination — et un recruteur qui voit CLF-C02 seul sur un CV, sans rien derrière, le lit exactement comme ça : un début, pas une preuve de compétence opérationnelle.

Ce qui ne se vérifie pas : le mythe du « tout GitHub, plus de certif »

C’est là que je corrige mon hypothèse de départ. Une bonne partie du contenu qui circule en ce moment affirme qu’un portfolio GitHub aurait purement et simplement remplacé la certification dans les critères de recrutement IT. Le problème : ce narratif s’appuie systématiquement sur des articles de blog qui se citent entre eux, jamais sur des données d’offres d’emploi réelles ou des enquêtes sectorielles vérifiables. Aucune des sources chiffrées que j’ai trouvées — ni itjobswatch, ni Skillsoft — ne montre de recul du poids des certifications AWS dans les critères de recrutement technique.

Ce que montrent les chiffres, c’est l’inverse d’un remplacement : c’est un cumul qui devient la norme. Skillsoft observe que les professionnels IT s’appuient de plus en plus sur une combinaison de certifications techniques (67 %), de compétences technologiques pratiques (66 %) et de compétences comportementales (56 %) pour se différencier — pas sur l’un au détriment de l’autre. Le retour de terrain que j’ai lu va dans le même sens : « utiliser la certification et un projet concret ensemble sur un CV est bien plus convaincant que la certification seule ». Ce n’est pas GitHub contre AWS. C’est AWS Solutions Architect plus un projet concret qui gagne face à AWS Cloud Practitioner tout seul — et c’est un écart de logique complètement différent du narratif qu’on lit partout.

Ce que ça change si vous préparez une certification AWS aujourd’hui

Concrètement, ça ne veut pas dire qu’il faut sauter le Cloud Practitioner — pour un profil non technique ou une première approche du cloud, il reste le point d’entrée le plus accessible et le mieux reconnu. Ce que les chiffres disent, c’est qu’il faut le traiter comme une étape et pas comme un point d’arrivée. Si vous êtes déjà dans un rôle technique (dev, ops, data), le signal du marché est clair : la valeur salariale se joue sur les certifications Associate, avec un écart de plusieurs dizaines de milliers d’euros à la clé, pas sur l’accumulation de badges d’entrée de gamme.

Concrètement pour la préparation, ça change aussi la manière de bachoter. Un Cloud Practitioner se prépare sur la définition des services. Un Solutions Architect Associate se prépare sur les compromis entre services — pourquoi choisir Lambda plutôt que Fargate, pourquoi RDS plutôt que DynamoDB dans tel scénario. C’est d’ailleurs déjà le genre de confusion qui coûte des points dès le Cloud Practitioner — on l’a détaillé dans notre article sur le piège EC2/Lambda/Fargate — et c’est ce changement de nature des questions, pas juste leur volume, qui explique l’écart de valeur perçue par les recruteurs entre les deux niveaux de certification.

Le même phénomène de dilution du signal touche d’ailleurs les certifications IA les plus récentes, à mesure qu’elles se banalisent : voir notre décryptage sur le piège fine-tuning/RAG/prompt engineering de l’AIF-C01, un autre domaine où la définition ne suffit plus, il faut savoir trancher entre approches.

Si vous êtes sur le CLF-C02 en ce moment, notre examen blanc AWS Cloud Practitioner reste un bon outil pour sécuriser cette première étape — l’essentiel est de ne pas s’arrêter là si votre objectif est un poste technique.

L’article AWS Cloud Practitioner vs Solutions Architect : ce que le marché de l’emploi paie vraiment en 2026 est apparu en premier sur MyExam.fr.

Le piège : traiter « Advanced Level » comme une case à cocher

Le mot « Advanced » laisse penser à un niveau supérieur générique, dans la continuité directe du Foundation — un peu comme passer du B1 au B2 en langue. Ce n’est pas ce que couvre réellement l’ISTQB. Le guide officiel ASTQB est très clair sur ce point : le CTAL-TM valide des compétences de pilotage — planification, gestion d’équipe, reporting aux parties prenantes, gestion des risques projet. Le CTAL-TA (Test Analyst), lui, approfondit la conception de tests et l’analyse fonctionnelle — un renforcement direct du métier de testeur, pas un saut vers le management. Ce sont deux trajectoires professionnelles différentes qui partagent juste un même prérequis.

Pourquoi cette confusion est aussi répandue

Trois raisons expliquent pourquoi tant de testeurs se dirigent vers le CTAL-TM sans se poser la question :

• Les guides de carrière listent le Test Manager en premier. Plusieurs ressources de préparation présentent explicitement le parcours comme « de CTFL à CTAL » — au singulier — alors que trois branches existent en parallèle. Le Test Manager, plus visible dans le vocabulaire courant (« passer manager »), devient le choix par défaut par simple effet de familiarité.
• Beaucoup d’organismes de formation ne vendent qu’une seule certification Advanced. myexam.fr ne fait pas exception : nous ne proposons aujourd’hui que l’examen blanc CTAL-TM, pas CTAL-TA ni CTAL-TTA. Quand un site ne montre qu’une option, il est facile de croire que c’est la seule qui existe.
• Le terme « Advanced » n’a pas d’équivalent univoque en français. On l’associe spontanément à « niveau supérieur » plutôt qu’à « spécialisation » — alors que la structure ISTQB fonctionne bien plus comme un embranchement que comme un escalier.

La vraie carte des 3 parcours Advanced

Voici, en résumé et d’après la documentation officielle, ce que couvre réellement chaque parcours :

• Test Manager (CTAL-TM) : conception de la stratégie de test, constitution et pilotage d’une équipe, métriques et reporting, gestion des risques et des parties prenantes. Pour ceux qui veulent arrêter de tester eux-mêmes et prendre la responsabilité d’une équipe ou d’un projet de test.
• Test Analyst (CTAL-TA) : techniques de conception de tests fonctionnels, analyse des exigences métier, tests d’acceptation utilisateur. Pour ceux qui veulent approfondir le cœur du métier de testeur, sans bifurquer vers le management.
• Technical Test Analyst (CTAL-TTA) : tests basés sur les risques, tests boîte blanche, analyse statique et dynamique, tests non fonctionnels, automatisation. Pour les profils qui veulent aller vers la technique pure et l’automatisation.

Ce que dit vraiment le marché de l’emploi

Si le CTAL-TM était réellement « la » suite logique pour la majorité des testeurs, on s’attendrait à ce que les recruteurs le demandent nettement plus que les autres parcours Advanced. Les données du marché britannique montrent l’inverse : selon itjobswatch.co.uk, sur les 6 mois précédant août 2026, les offres d’emploi permanentes mentionnant « Test Analyst » (12 offres, 11,1 % des postes citant l’ISTQB) sont légèrement plus nombreuses que celles mentionnant « Test Manager » (9 offres, 8,3 %). Le marché ISTQB dans son ensemble s’est d’ailleurs contracté de 27 % sur un an (147 à 108 offres), ce qui rend d’autant plus important de ne pas se tromper de parcours avant d’investir temps et argent dans un examen à 250 $.

Sur le terrain, la discussion « Is the ISTQB CTAL-TM exam challenging? » sur le forum Ministry of Testing va dans le même sens : les praticiens qui ont réussi l’examen insistent sur le fait qu’une véritable expérience de pilotage d’équipe de test aide bien davantage que la seule lecture du syllabus — un signal supplémentaire que ce parcours cible un profil précis, pas « la suite normale » pour tout testeur certifié Foundation.

Un exemple qui montre bien la différence de nature

Exemple représentatif du type de scénario couvert par le syllabus Test Management (pas une question officielle reproduite) : « Une équipe de test accuse un retard de deux sprints sur son plan de charge. Le chef de projet vous demande un plan d’action avant le comité de pilotage de vendredi. Quelle est la première action attendue d’un Test Manager dans cette situation ? »

Ce type de question ne teste ni une technique de conception de test, ni une compétence d’analyse fonctionnelle — il évalue la capacité à réévaluer les risques, prioriser et communiquer à des parties prenantes non techniques. C’est exactement la nature des questions du CTAL-TM : si ce genre de scénario vous semble éloigné de votre quotidien de testeur et que vous préféreriez qu’on vous demande plutôt de choisir la bonne technique de partitionnement en classes d’équivalence, c’est le signe le plus clair que le CTAL-TA correspondrait mieux à votre trajectoire — même si myexam.fr ne propose pas encore cet examen blanc.

Ce qu’il faut retenir avant de s’inscrire

Le CTAL-TM n’est ni meilleur ni pire que les deux autres parcours Advanced — il est simplement destiné à un projet de carrière précis : piloter des équipes et des projets de test, pas approfondir la pratique du test elle-même. Avant de vous inscrire à un examen à 250 $ qui recommande 3 à 5 ans d’expérience pour être vraiment à l’aise avec les questions à scénario, la bonne première étape reste de solidifier vos bases sur le Foundation Level v4.0 et de comprendre en détail ce que teste réellement chaque domaine du blueprint officiel — et si vous préparez déjà un Advanced, analyser finement vos résultats d’examen blanc vous dira plus vite que n’importe quel guide de carrière si vous êtes sur la bonne trajectoire.

L’article ISTQB : pourquoi le CTAL-TM n’est pas « la » suite logique après le Foundation est apparu en premier sur MyExam.fr.

Les 4 concepts que ce domaine teste systématiquement

Contrairement à d’autres domaines très techniques (chiffrement, architecture réseau), celui-ci teste surtout votre capacité à catégoriser correctement une situation décrite en scénario. Quatre points reviennent presque à chaque examen :

• Menace vs vulnérabilité vs risque : une vulnérabilité est une faiblesse exploitable (ex. un logiciel non patché), une menace est l’acteur ou l’événement qui peut l’exploiter, un risque est la probabilité de survenue combinée à l’impact. L’examen construit des questions entières autour de cette seule distinction.
• Acteurs de la menace et motivations : savoir associer un profil (État-nation, hacktiviste, menace interne, script kiddie, courtier d’accès initial) à sa motivation typique (espionnage, idéologie, vengeance, notoriété, profit) et à son niveau de ressources.
• Ingénierie sociale — canal vs technique : le canal (email = phishing, voix = vishing, SMS = smishing, en personne = tailgating) et la technique (pretexting, baiting, quid pro quo) sont deux axes de classification distincts et souvent combinés dans une même question.
• Cycle de vie d’une attaque ransomware : accès initial, exécution, mouvement latéral, exfiltration, chiffrement, extorsion. L’examen demande souvent d’identifier à quelle étape correspond un indicateur de compromission donné, pas seulement de reconnaître « c’est un ransomware ».

L’erreur de vocabulaire qui coûte le plus de points

La confusion la plus fréquente ne porte pas sur un concept technique complexe, mais sur la catégorisation d’un scénario d’ingénierie sociale. Beaucoup de candidats identifient d’abord la technique (le scénario inventé, la manipulation psychologique) et répondent « pretexting » par réflexe — alors que la question demande souvent de qualifier le canal utilisé. Un appel téléphonique frauduleux reste un cas de vishing même s’il repose sur un prétexte élaboré ; le pretexting est la technique sous-jacente, pas la catégorie principale attendue quand la question précise explicitement le moyen de contact.

Exemple de question type

Un employé reçoit un appel d’une personne se présentant comme un technicien du support IT, qui affirme devoir « confirmer son mot de passe » pour résoudre un incident urgent affectant son compte. Quel type d’attaque décrit le mieux ce scénario ?

• A. Phishing
• B. Vishing
• C. Pretexting
• D. Smishing

Réponse attendue : B. Vishing. L’énoncé précise explicitement le canal — un appel téléphonique — ce qui oriente directement vers le vishing (voice + phishing). Le piège classique est de répondre « pretexting » (C), qui décrit bien la technique employée (le faux prétexte du « problème urgent ») mais pas la catégorie principale que l’examen demande ici. Phishing (A) et smishing (D) sont éliminés dès la première lecture puisqu’aucun email ni SMS n’intervient dans le scénario.

Ce qu’il faut retenir avant l’examen

Le domaine « Threats, Vulnerabilities, and Mitigations » ne demande pas de mémoriser une liste de malwares, mais de savoir catégoriser rapidement et sans ambiguïté un scénario selon le bon axe de classification — canal plutôt que technique, étape du cycle de vie plutôt que nom générique de l’attaque. C’est aussi le domaine où une bonne méthode d’analyse de vos résultats d’examen blanc paie le plus : repérer si vos erreurs viennent d’un manque de connaissance ou d’une confusion de catégorisation change complètement la façon de réviser. Le même type de piège de vocabulaire technique se retrouve d’ailleurs sur d’autres certifications, comme la confusion EC2 vs Lambda vs Fargate sur l’AWS CLF-C02 ou la distinction IaaS/PaaS/SaaS sur l’AZ-900.

L’article CompTIA SY0-701 — Le domaine Menaces, vulnérabilités et mitigations décrypté (22 % de l’examen) est apparu en premier sur MyExam.fr.

Le piège qui revient sur le domaine le plus pondéré de l’examen

Face à un scénario du type « une entreprise veut que son modèle réponde avec les informations les plus récentes de son catalogue produit », beaucoup de candidats répondent instinctivement « fine-tuning » — parce que c’est le terme le plus familier, celui qu’on associe spontanément à « personnaliser un modèle IA ».

C’est presque toujours la mauvaise réponse. Et l’inverse existe aussi : des scénarios où RAG semble la solution « moderne » par défaut, alors que la bonne réponse est prompt engineering, voire aucune modification du modèle. Ce piège n’est pas isolé — on retrouve la même logique de confusion sur d’autres certifications AWS, comme le choix entre EC2, Lambda et Fargate sur le CLF-C02.

Pourquoi cette confusion est si fréquente

Les trois techniques répondent à la même question de surface — « comment faire dire au modèle ce que je veux ? » — mais à des niveaux complètement différents :

• Prompt engineering : on ne touche ni aux poids du modèle ni à ses sources de données. On reformule uniquement l’instruction envoyée au modèle (chain-of-thought, zero-shot, few-shot).
• RAG : le modèle reste inchangé, mais on lui injecte, au moment de la requête, des informations externes récupérées dans une base de connaissances.
• Fine-tuning : le modèle est réentraîné sur un jeu de données spécifique, ce qui modifie ses poids de façon durable.

L’examen AIF-C01 ne demande jamais « quelle est la définition du fine-tuning ? ». Il pose des scénarios métier et attend que vous identifiiez le bon outil selon trois critères : la fraîcheur des données nécessaires, le coût et la complexité acceptables, et si le besoin porte sur le contenu (les faits) ou sur le comportement (le style, le format, le ton).

3 questions type AIF-C01 — et pourquoi la bonne réponse surprend

Question 1 — Catalogue produit à jour

Une entreprise e-commerce veut qu’un chatbot réponde aux questions clients avec les prix et stocks actuels, qui changent plusieurs fois par jour. Quelle approche recommander ?

Réponse attendue : RAG. Le fine-tuning capturerait un instantané du catalogue au moment de l’entraînement, obsolète en quelques heures. RAG permet d’interroger une base de données à jour à chaque requête, sans réentraîner le modèle.

Question 2 — Ton et structure imposés

Un cabinet juridique veut qu’un modèle génère systématiquement des résumés de contrats dans un format et un ton précis, indépendamment du contenu du contrat. Quelle approche recommander ?

Réponse attendue : fine-tuning. Il ne s’agit pas d’injecter des faits externes, mais de faire adopter au modèle un comportement stable et reproductible — exactement le cas d’usage du fine-tuning.

Question 3 — Test rapide sans budget de données

Une équipe veut évaluer, en quelques heures et sans jeu de données d’entraînement, si un modèle de fondation existant peut résumer des tickets support de façon satisfaisante. Quelle approche recommander ?

Réponse attendue : prompt engineering. Aucune donnée externe n’est nécessaire, aucun réentraînement n’est justifié pour un simple test — on commence toujours par la solution la moins coûteuse avant d’envisager RAG ou fine-tuning.

Ce qu’il faut retenir avant l’examen

Le domaine « Applications of Foundation Models » ne teste pas votre capacité à réciter des définitions, mais votre capacité à choisir le bon outil selon le contexte métier. La question à se poser systématiquement face à un scénario : est-ce que le problème porte sur des faits qui changent, sur un comportement à stabiliser, ou sur rien de plus qu’une meilleure formulation ? Une fois ce réflexe acquis, la méthode d’analyse de vos résultats d’examen blanc vous aidera à repérer si ce domaine reste un point faible avant le jour J.

L’article AWS AIF-C01 : Fine-tuning, RAG ou Prompt Engineering — le piège qui coûte des points sur 28 % de l’examen est apparu en premier sur MyExam.fr.

PSM I et PSM II : deux examens qui n’ont rien à voir

Le PSM I valide votre connaissance du Scrum Guide : rôles, événements, artefacts, définitions. Le PSM II part du principe que ces bases sont acquises et teste votre jugement situationnel face à des scénarios ambigus — coaching d’équipe, résistance au changement, systèmes adaptatifs complexes. Ce n’est pas « PSM I mais plus dur » : c’est un examen d’une autre nature.

Tableau comparatif complet

Le profil candidat idéal pour chacun

Pour qui est fait le PSM I

Le PSM I s’adresse à toute personne qui débute ou formalise sa pratique Scrum : développeur qui rejoint une équipe agile, chef de projet en reconversion, product owner qui veut sécuriser son vocabulaire, ou futur Scrum Master sans certification. Il valide un socle commun — utile même pour des rôles qui ne sont pas « Scrum Master » au sens strict.

Pour qui est fait le PSM II

Le PSM II vise les Scrum Masters qui exercent déjà le rôle depuis plusieurs mois, qui ont animé des rétrospectives difficiles, géré des conflits d’équipe ou négocié avec des parties prenantes réticentes. Sans cette pratique de terrain, les scénarios de l’examen restent abstraits et le taux d’échec grimpe fortement — ce n’est pas un examen qui se prépare uniquement sur des flashcards.

Faut-il vraiment passer les deux ?

Oui, si votre objectif est d’exercer durablement le rôle de Scrum Master. Le PSM I ouvre la porte, le PSM II la consolide et devient un vrai différenciateur sur le marché — beaucoup de candidats s’arrêtent au niveau I, ce qui rend le niveau II plus rare et plus valorisé en entretien.

Non, si vous cherchez uniquement une certification d’appoint pour un rôle de product owner, développeur ou chef de projet occasionnellement agile. Dans ce cas, le PSM I suffit largement et le PSM II représente un investissement de temps disproportionné par rapport au bénéfice.

Vous hésitez encore entre la voie Scrum Master et la voie Product Owner ? Notre comparatif PSPO vs PSM : quelle certification Scrum choisir en 2026 aide à trancher selon votre rôle actuel. Et pour creuser précisément ce qui est testé au niveau I, notre décryptage PSPO I : les 4 concepts que Scrum.org teste systématiquement reste pertinent pour comprendre la logique d’évaluation de Scrum.org, même côté Scrum Master.

Quel que soit le niveau visé, la méthode de préparation change peu : multipliez les examens blancs et analysez chaque erreur en détail plutôt que de relire passivement le Scrum Guide. Notre guide comment analyser ses résultats d’examen blanc pour progresser vite détaille cette méthode.

L’article PSM I vs PSM II : faut-il vraiment passer les deux certifications Scrum Master ? est apparu en premier sur MyExam.fr.

Ce qu’ITIL 4 Foundation teste vraiment

L’examen ITIL 4 Foundation n’est pas un test de mémorisation de processus. C’est une évaluation de votre compréhension du Système de Valeur des Services (SVS) — le cadre central d’ITIL 4 — et de sa mise en pratique dans des scénarios concrets.

Les 5 grands domaines couverts par le syllabus :

• Concepts clés du management des services — valeur, service, co-création, parties prenantes
• Le modèle des 4 dimensions — organisations, information, partenaires, flux de valeur
• Le Système de Valeur des Services (SVS) — la chaîne de valeur, les principes directeurs, la gouvernance
• Les 7 principes directeurs — « se concentrer sur la valeur », « commencer là où on est », « progresser par itération »…
• Les 15 pratiques fondamentales — gestion des incidents, des problèmes, des changements, du catalogue de services…

ITIL 4 vs ITIL v3 : la vraie rupture

ITIL v3 était structuré en 5 livres de cycles de vie avec 26 processus. ITIL 4 abandonne cette logique séquentielle pour une approche systémique. Les 26 processus sont devenus 34 pratiques, délibérément plus souples pour s’intégrer dans des contextes agile et DevOps.

Pour un professionnel certifié ITIL v3, la transition vers ITIL 4 Foundation ne repart pas de zéro. Les concepts fondamentaux (incidents, problèmes, changements, niveaux de service) sont toujours présents — le cadre conceptuel autour est différent.

ITIL 4 Foundation en 2026 : le marché dit quoi ?

Quelques données concrètes pour répondre à la question « encore utile ? » :

• 6 millions de professionnels certifiés ITIL dans le monde (PeopleCert, 2024) — c’est la certification ITSM la plus répandue, loin devant ses concurrentes
• Dans les offres d’emploi françaises liées à la gestion des services IT (ITSM, responsable support, DSI), ITIL apparaît dans plus de 70 % des fiches de poste pour les profils seniors
• ITIL 4 est compatible avec les frameworks agile (SAFe, Scrum) et DevOps — ce que v3 ne permettait pas sans adaptation significative

La certification est particulièrement pertinente pour les profils : gestionnaires de services IT, responsables support N2/N3, chefs de projet ITSM, DSI en transition vers l’agilité.

Les 3 erreurs qui font rater l’examen

1. Mémoriser les définitions sans comprendre les scénarios. L’examen ITIL 4 Foundation est conçu pour tester l’application des concepts, pas leur récitation. Une question type : « Un utilisateur signale que son ordinateur ne démarre plus depuis une mise à jour. Quelle pratique ITIL est la plus appropriée ? » — la réponse exige de distinguer incident management et problem management dans un contexte précis.

2. Confondre les 34 pratiques avec les 15 pratiques du syllabus Foundation. L’examen ne couvre que 15 des 34 pratiques — les 19 restantes appartiennent aux niveaux supérieurs (Practitioner, Strategic Leader). Concentrez-vous sur les 15 pratiques fondamentales.

3. Sous-estimer les principes directeurs. Avec un seuil à 65 %, une mauvaise maîtrise des 7 principes suffit à faire échouer. Ce domaine est transversal — il intervient dans des questions de tous les autres domaines.

Vous préparez également d’autres certifications de gestion de projet ou de services ? Notre comparatif PMP vs PRINCE2 en 2026 peut vous aider à prioriser votre parcours de certification.

L’article ITIL 4 Foundation en 2026 : la certification ITSM encore incontournable ? est apparu en premier sur MyExam.fr.

Les 4 concepts systématiquement testés

1. Product Goal — la destination, pas la liste de fonctionnalités

Le Scrum Guide 2020 introduit le Product Goal comme un engagement du Product Backlog : c’est l’objectif à long terme que le produit doit atteindre. Les questions testent si vous distinguez un Product Goal (résultat à atteindre) d’une liste de fonctionnalités à livrer (outputs).

Erreur fréquente : confondre « vision produit » et « Product Goal ». La vision est un cap général, souvent qualitatif. Le Product Goal est un objectif mesurable, inscrit dans le Product Backlog comme sa direction concrète.

2. Product Backlog — ordonnancement, pas priorisation

Le Scrum Guide 2020 dit que le Product Owner ordonne le Product Backlog — et non qu’il le « priorise ». Ce choix de vocabulaire est délibéré et testé.

Erreur fréquente : choisir « le Product Owner priorise le backlog » comme réponse correcte. Sur l’examen, le terme attendu est ordonne. L’ordonnancement repose sur une combinaison de valeur, risque, dépendances et taille — pas uniquement sur la valeur financière.

3. Valeur — plus large que vous ne le pensez

Sur le PSPO I, « valeur » n’est jamais limitée au chiffre d’affaires. Une fonctionnalité peut avoir de la valeur parce qu’elle réduit un risque légal, améliore la satisfaction utilisateur, accélère l’apprentissage ou répond à une contrainte stratégique.

Erreur fréquente : choisir systématiquement « la fonctionnalité qui génère le plus de revenus » quand la question porte sur la valeur globale. Scrum.org attend une vision multidimensionnelle : la valeur est définie du point de vue du client et du marché, pas uniquement du département financier.

4. Stakeholders — le PO décide, les parties prenantes influencent

Le Product Owner est redevable envers les parties prenantes — mais il prend les décisions d’ordonnancement de façon autonome. Les stakeholders n’ont pas de droit de veto sur le Product Backlog.

Erreur fréquente : penser que les stakeholders « approuvent » ou « valident » le backlog avant chaque Sprint. Le Scrum Guide est explicite : le Product Owner est la seule personne responsable du Product Backlog. Les parties prenantes peuvent influencer — pas décider.

Une question type avec analyse complète

« Lors du Sprint Review, un stakeholder clé est absent. Il demande au Product Owner une présentation séparée de l’incrément la semaine suivante. Que doit faire le Product Owner ? »

Réponse correcte : Le Product Owner peut décider de partager l’incrément via d’autres canaux — démo enregistrée, documentation, accès direct au produit. Une réunion formelle supplémentaire n’est pas requise par Scrum. Ce qui compte : l’information est accessible, le feedback peut remonter.

Réponses pièges à éviter :

• « Demander au Scrum Master de présenter à sa place » — faux. Les décisions sur la valeur produit relèvent de la responsabilité du PO, pas du Scrum Master.
• « Rejouer le Sprint Review pour ce stakeholder » — faux. L’événement a eu lieu ; Scrum ne prévoit pas de répétition.
• « Refuser catégoriquement toute présentation séparée » — faux. Le PO peut choisir de partager l’incrément librement — Scrum n’interdit pas les échanges informels.

Pour aller plus loin

Vous hésitez entre PSPO I et PSM I ? Notre comparatif PSPO vs PSM : quelle certification Scrum choisir en 2026 vous aide à choisir selon votre profil et vos objectifs.

Après vos premiers examens blancs, la méthode d’analyse de résultats est aussi importante que la révision elle-même. Notre guide sur comment analyser ses résultats d’examen blanc pour progresser vite vous donne un cadre concret.

L’article PSPO I — Managing Products with Agility : les 4 concepts que Scrum.org teste systématiquement est apparu en premier sur MyExam.fr.

Le piège : vous raisonnez du côté d’Azure, pas du vôtre

Le réflexe erroné le plus fréquent : « Azure gère l’OS, donc c’est du PaaS ». Ce raisonnement est inversé. Ce qui définit un modèle de service, ce n’est pas ce que le fournisseur fait — c’est ce que vous, en tant que client, contrôlez réellement.

Pourquoi cette confusion est si fréquente

Le modèle de responsabilité partagée déplace la frontière selon le service choisi. Plus vous montez vers le SaaS, plus Azure prend en charge — mais la question à se poser reste toujours la même : qu’est-ce que le client configure ?

La règle mnémotechnique : « Qui configure l’OS ? »

Trois questions à vous poser face à un scénario d’examen :

• IaaS — Vous installez et configurez l’OS vous-même.
• PaaS — L’OS est transparent, géré par Azure. Vous déployez votre code, rien d’autre.
• SaaS — Vous êtes utilisateur, pas développeur ni administrateur.

3 questions types avec analyse

Question 1 — Déploiement de VMs

« Une PME déploie des machines virtuelles sur Azure et installe elle-même IIS et SQL Server sur ces VMs. »

Réponse : IaaS. La PME configure l’OS et installe les logiciels. Azure ne gère que le matériel sous-jacent.

Piège classique : « Azure héberge les VMs donc c’est du PaaS. » Non — ce qui compte : la PME touche-t-elle l’OS ? Oui. Donc IaaS.

Question 2 — Azure App Service

« Un développeur déploie son application Python sur Azure App Service. Il n’a jamais configuré l’OS ni les correctifs de sécurité du serveur. »

Réponse : PaaS. App Service gère le runtime, l’OS et les patches. Le développeur ne touche qu’au code.

Question 3 — Microsoft 365

« Une équipe utilise Microsoft Teams et Exchange Online pour ses communications. Elle n’administre aucun serveur. »

Réponse : SaaS. L’équipe est utilisatrice du logiciel. Elle ne gère ni infrastructure, ni OS, ni code.

Cas limite à connaître : Azure SQL Database

Azure SQL Database = PaaS. Microsoft gère le moteur SQL Server, les patches, la haute disponibilité. Vous gérez uniquement vos données et vos requêtes SQL.

En revanche, SQL Server installé sur une VM Azure = IaaS. Vous gérez vous-même le moteur de base de données, les mises à jour, la configuration.

Si vous préparez également la certification DP-900 Azure Data Fundamentals, vous retrouverez cette distinction dans les questions sur les services de données managés Azure — les deux certifications se complètent parfaitement.

L’article AZ-900 : IaaS, PaaS ou SaaS — la confusion qui coûte des points à 40 % des candidats est apparu en premier sur MyExam.fr.