Expliquer vos décisions

Ce que vous saurez faire

Expliquez un projet de façon à inspirer confiance. Votre façon d’expliquer vos choix et vos échecs renseigne davantage les responsables d’entrevue et vos collègues que votre liste d’outils.

Avant de commencerCe qu’il faut savoir et avoir sous la mainEnviron 30 minutes

Ce que vous devez savoir

• Les parties d’un bon README et comment relier chaque affirmation à une preuve, selon Les éléments d’un portfolio : les parties d’un bon README et Les éléments d’un portfolio : relier chaque affirmation à une preuve.

Ce qu’il vous faut

• Vos deux fiches de projet, sous ## Project briefs (fiches de projet) dans notes.md, tirées de Les éléments d’un portfolio : exercice guidé : deux fiches de projet.
• Pour l’exercice, un moyen de mesurer deux minutes, comme l’horloge de votre téléphone.

Racontez la décision, pas seulement le résultat

« J’ai créé un outil de détection des factures en double en Python » indique ce qui existe. Cela ne montre pas votre façon de réfléchir. Un récit de décision le fait. Il comporte cinq parties :

1. La situation : ce que vous deviez décider.
2. Les options : au moins deux possibilités réelles.
3. Le choix et sa raison : votre choix et pourquoi il convenait à ce problème.
4. Le coût : ce que votre choix a rendu moins bon. Chaque choix a un coût.
5. Avec le recul : ce que vous garderiez ou changeriez maintenant.

Voici le récit de décision de Daniela :

Je devais choisir entre des règles fixes et un modèle d’apprentissage automatique pour trouver les doublons. Un modèle pourrait apprendre des régularités auxquelles je n’avais pas pensé. Mais je connaissais les types de problèmes grâce à mon travail, et je n’avais pas de données réelles étiquetées. Les comptables doivent aussi pouvoir vérifier pourquoi une facture a été signalée. J’ai donc choisi des règles. Le coût, c’est que les règles manquent les types de doublons que je n’ai pas prévus, comme ceux après un crédit partiel. Avec le recul, je garderais les règles. J’ajouterais un rapport sur les cas presque détectés pour rendre visibles de nouveaux types de problèmes.

Cela prend environ 40 secondes. Le récit montre une connaissance du domaine, une autre option réelle, une raison liée aux utilisateurs, un coût reconnu et une prochaine étape.

Parlez des cas d’échec

Tout système échoue dans certaines situations. Les personnes qui ont créé de vrais systèmes le savent et cherchent cette information. Dire où votre projet échoue n’est pas une faiblesse. Cela montre que vous l’avez testé.

Une bonne description d’échec présente un cas précis, sa cause et ce que vous avez fait ou feriez :

Faible : « Ça fonctionne bien dans la plupart des cas. »

Solide : « L’outil manque deux des 24 doublons. Dans les deux cas, le fournisseur a envoyé un crédit partiel, donc les montants des factures diffèrent. J’ai documenté cette limite plutôt que d’assouplir les critères de correspondance. Des critères plus souples donnaient 15 fausses alertes au lieu de 3. »

Dites exactement ce que vous avez fait

Dans les projets d’équipe, la personne qui vous écoute doit connaître votre contribution. « Nous » la cache. Utilisez « je » pour votre travail, et « nous » ou un nom de rôle pour celui des autres.

Exagéré ou vague	Honnête et précis
« J’ai créé un système d’IA pour les factures. »	« J’ai écrit un script Python à base de règles qui signale les factures probablement en double. »
« Nous avons créé le classificateur. »	« L’ingénieur en apprentissage automatique a entraîné le modèle. J’ai rédigé les données de test : 300 billets de soutien concernant les garanties. J’ai trouvé pourquoi les résultats concernant les garanties étaient faibles. »
« Son exactitude est de 99 %. »	« Sur 200 factures synthétiques, il a trouvé 22 des 24 doublons ajoutés, avec 3 fausses alertes. »
« Expert en apprentissage automatique. »	« Cours terminés en Python et en statistiques. Un projet avec une référence de base et une évaluation. »

Un langage honnête ne diminue pas la valeur de votre travail. Les responsables d’entrevue posent des questions de suivi. Une affirmation exagérée ne résiste pas à la deuxième question, puis ils doutent de tout le reste. Une affirmation précise résiste à chaque question, parce qu’elle est vraie.

La présentation de deux minutes

Une présentation est une courte explication orale d’un projet, par exemple au début d’une entrevue. Deux minutes correspondent à environ 250 à 300 mots à l’oral. Suivez cette structure :

Temps	Partie	Contenu
0:00–0:20	Problème	Qui le rencontre et pourquoi il compte.
0:20–0:40	Données et approche	Ce que vous avez utilisé et créé, en une ou deux phrases.
0:40–1:10	Une décision	Un court récit de décision.
1:10–1:35	Évaluation et échec	Le résultat comparé à la référence de base et un cas d’échec.
1:35–2:00	Limites, prochaine étape, votre contribution	Ce que vous feriez ensuite et ce que vous avez fait vous-même.

Cette durée de deux minutes est volontairement courte. La personne qui vous écoute choisit les prochaines questions. Une bonne présentation lui donne envie d’en poser.

Exemple détaillé : le plan de présentation de Daniela

Un plan contient des notes, pas un texte à réciter. Daniela écrit :

• Problème : les équipes de comptabilité paient des factures deux fois, car une même facture arrive par courriel et par la poste avec de petites différences. Au travail, nous en trouvions plusieurs chaque année, généralement après le paiement.
• Données et approche : 200 factures synthétiques, 24 doublons ajoutés. Un script Python qui nettoie les numéros de facture et compare le fournisseur, le montant et le numéro.
• Décision : règles ou modèle. Règles, parce que je connaissais les types de problèmes et n’avais pas de données réelles étiquetées. Les comptables doivent voir pourquoi une facture a été signalée.
• Évaluation et échec : la correspondance exacte en a trouvé 12 sur 24. Mon outil en a trouvé 22, avec 3 fausses alertes. Il manque les doublons après des crédits partiels.
• Suite et ma contribution : tester sur un jeu de données public de factures, signaler les cas presque détectés. J’ai tout fait moi-même. Les types de problèmes viennent de sept années en comptabilité.

Exercice guidé : votre présentation

1. Dans notes.md, ajoutez un titre : ## Walkthrough (présentation).
2. Rédigez un plan de présentation pour votre projet 1, avec les cinq parties. Utilisez des notes, pas des phrases complètes.
3. Rédigez un récit de décision avec les cinq parties : situation, options, choix et raison, coût, regard avec le recul.
4. Faites la présentation à voix haute et chronométrez-la.
5. Si elle dépasse deux minutes, retirez des détails de l’approche, pas de la décision ni du cas d’échec.

Votre projet n’est peut-être pas encore terminé. Rédigez alors le plan avec vos décisions prévues et les résultats attendus, en les indiquant comme tels. Mettez-le à jour une fois le projet terminé.

Vérification : votre présentation contient une référence de base, un cas d’échec et une phrase claire sur votre contribution. Elle ne contient aucune affirmation que vos preuves ne peuvent appuyer.

Variante autonome : demandez à un ami ou à un collègue de vous écouter, puis de vous poser deux questions. Notez les questions. Elles révèlent ce qui manquait de clarté et ce que les responsables d’entrevue pourraient demander.

Erreur courante

Exagérer pour impressionner

Symptôme : en entrevue, vous décrivez votre projet comme « un système d’IA qui automatise la vérification des factures ». La personne demande : « Quel modèle avez-vous utilisé et comment l’avez-vous entraîné? » Vous devez expliquer qu’il n’y a pas de modèle. Elle doute maintenant de vos autres réponses.

Cause : vous avez choisi les mots les plus impressionnants, pas ceux qui décrivent le travail.

Solution : décrivez exactement le travail : « un script à base de règles ». Expliquez ensuite pourquoi les règles étaient le bon choix. Une raison claire pour une solution simple impressionne davantage les personnes d’expérience qu’un grand mot sans raison.

Vérifiez votre compréhension

Pourquoi un récit de décision doit-il inclure le coût du choix?

Afficher la réponse

Parce que chaque choix réel a un coût, et les personnes d’expérience le savent. Nommer ce coût montre que vous avez comparé de vraies options et compris le compromis. Sans coût nommé, vous semblez ne pas avoir vu les autres options, ou cacher le point faible.

Vérifiez votre compréhension

Dans un projet d'équipe, une autre personne a entraîné le modèle. Vous avez créé l'évaluation. Comment décrivez-vous votre contribution?

Afficher la réponse

Dites-le exactement : « Un collègue a entraîné le modèle. J’ai créé l’évaluation : j’ai choisi les cas de test, rédigé les règles de notation et trouvé la cause des faibles résultats concernant les garanties. » Utilisez « je » pour votre travail et nommez le rôle pour celui des autres. L’évaluation est un travail précieux. Le dire clairement est plus convaincant qu’un vague « nous avons créé un modèle ».

Récapitulatif

• Racontez des récits de décision : situation, options, choix et raison, coût et regard avec le recul.
• Décrivez précisément les cas d’échec. Cela montre que vous avez testé votre travail.
• Dites exactement ce que vous avez fait. Utilisez « je » pour votre travail et nommez les rôles des autres.
• Une présentation de deux minutes couvre le problème, l’approche, une décision, l’évaluation avec un échec et votre contribution.

Ensuite, vous relierez vos preuves à une offre d’emploi réelle et planifierez votre préparation aux entrevues.

Leçon suivante : Se préparer aux candidatures