Deux assistants, deux portfolios
Un portfolio d'ingénieur IA, c'est le travail que vous montrez à un employeur, et il doit montrer comment vous décidez. Deux personnes présentent chacune un assistant conversationnel. La première partage une capture d'écran. La seconde partage un tableau d'évaluation, la liste des échecs connus et le coût d'une semaine.
Un recruteur apprend bien plus avec la seconde. Cette leçon montre comment construire ce second portfolio à partir de vos projets.
À la fin de cette leçon
Remarque
Je peux vérifier un projet de portfolio avec une liste de contrôle qui montre du jugement.
Mots clés
| Mot | Ce que ça veut dire |
|---|---|
| Portfolio | le travail que vous montrez à un employeur |
| Dépôt | le dossier d'un projet, avec ses fichiers et son historique |
| README | le premier fichier qu'un visiteur lit |
| Limites connues | ce que le projet fait mal, dit clairement |
| Reproductible | quelqu'un d'autre peut le lancer et obtenir les mêmes résultats |
Les cellules que les étudiants remplissent restent vides dans cet aperçu.
Un README dit quoi, pourquoi et comment
Un visiteur accorde une minute ou deux à votre dépôt. Le README doit tenir cette minute.
Dites en une phrase ce que fait le projet. Dites pourquoi vous l'avez fait, et pour qui. Puis dites comment le lancer en quelques étapes, avec des données d'exemple fixes, pour qu'il soit reproductible. Placez les résultats d'évaluation en haut, pas en bas.
Exemple travaillé : le plan d'un README
| Titre | Ce qu'on écrit dessous |
|---|---|
| Ce que fait le projet | Une phrase : répond aux salariés à partir de 40 notes internes |
| Pourquoi je l'ai fait | Le problème, et qui l'a |
| Comment le lancer | Trois étapes, avec les documents d'exemple fournis |
| Résultats d'évaluation | 18 justes sur 20, aucune invention, avec la date du passage |
| Limites connues | Lent sur les longs documents ; rate les questions sur les tableaux |
| Ce que je ferais ensuite | Une ou deux modifications, chacune avec sa raison |
Les cellules que les étudiants remplissent restent vides dans cet aperçu.
Preuves et limites montrent le jugement
Tout le monde peut affirmer qu'une fonctionnalité marche. Une preuve est un chiffre vérifiable : un score d'évaluation, un coût, une latence.
Les limites connues comptent tout autant. Dire où votre projet échoue montre que vous l'avez testé. Cela montre aussi que vous savez quoi corriger ensuite. Le programme compare les titres d'un README à une liste de contrôle.
À vous : vérifier un README
# Les titres trouvés dans le README d'un projet.
titres = ["Ce que fait le projet", "Comment le lancer", "Résultats d'évaluation"]
liste_controle = [
"Ce que fait le projet",
"Pourquoi je l'ai fait",
"Comment le lancer",
"Résultats d'évaluation",
"Limites connues",
"Ce que je ferais ensuite",
]
manquants = 0
for element in liste_controle:
if element in titres:
print("présent ", element)
else:
print("manquant", element)
manquants = manquants + 1
print(manquants, "sur", len(liste_controle), "manquants")
# Ajoutez "Limites connues" à titres, puis relancez.
Sûr, honnête et à vous
Avant de rendre un dépôt public, vérifiez trois choses. Aucun secret : ni clé ni mot de passe, nulle part dans l'historique. Aucune donnée personnelle : utilisez des noms inventés et des documents d'exemple.
Et il est à vous : dites quelles parties un assistant a écrites, et citez le code que vous avez repris. Ajoutez une licence, pour que les autres sachent ce qu'ils ont le droit d'en faire.
Une erreur fréquente
Attention
Beaucoup pensent qu'un portfolio ne doit montrer que ce qui marche. Cacher tous les échecs donne l'impression de n'avoir jamais testé. Donnez les limites connues et ce que vous feriez ensuite, car c'est ce jugement qu'une personne qui recrute cherche.