L'experte du domaine

Beaucoup de gens arrivent en ingénierie de l’IA après avoir exercé le métier auquel le logiciel est destiné. Ces personnes travaillaient en soins infirmiers, en comptabilité ou en expertise en sinistres. Chaque jour, elles voyaient la même tâche prendre du temps. Puis, un soir, elles ont commencé à apprendre Python pour régler le problème.

Ces personnes postulent souvent avec un doute : « Les autres ont des diplômes et des années de programmation. Qu’est-ce que j’ai, moi? » La réponse : beaucoup de choses. Elles savent quelles erreurs sont dangereuses. Elles savent ce que les utilisateurs font réellement et quelles règles s’appliquent. Notre leçon Votre expérience est une longueur d’avance explique pourquoi.

Mais la connaissance du domaine ne remplace pas l’ingénierie, et une entrevue sérieuse vérifie les deux. Suivons Leila pendant l’entrevue technique approfondie. Observez où son expérience mène la conversation et où ses connaissances s’arrêtent.

LH

La personne candidate

Leila Haddad

Cheffe d'équipe en règlement de sinistres, 11 ans en assurance de dommages, a appris à créer des outils

• 11 ans en règlement de sinistres en assurance de dommages
• Experte en sinistres pendant 7 ans, cheffe d'équipe pendant 4 ans
• Python, 2 ans (en soirée)
• Mississauga, Ontario

• Cheffe d’équipe, sinistres en assurance de biens, Northgate Mutual (depuis 2022). Dirige 9 experts en sinistres qui traitent des réclamations en assurance habitation et de petits immeubles commerciaux en Ontario.
• A créé un outil de tri des courriels par IA pour l’équipe de règlement de sinistres. Il classe les courriels entrants dans 7 catégories et rédige des accusés de réception. Utilisé chaque jour par 9 experts en sinistres, pour environ 140 courriels par jour.
• A vérifié l’outil manuellement sur 300 vrais courriels. A repéré et corrigé une confusion entre les courriels de subrogation et les nouvelles réclamations.
• Experte en sinistres, assurance de biens, Northgate Mutual (2015 à 2022). Dégâts d’eau, incendies, vols et dommages causés par le vent; soutien pour les sinistres majeurs.
• Parcours d’apprentissage en ligne en Python, en API et en apprentissage automatique, avec certificats (2024 à 2026).

Ce que Nadia voit avant l’appel

Nadia lit le CV à côté de l’offre d’emploi. Leila ne répond pas aux principales exigences. Elle n’a pas quatre ans d’expérience en développement logiciel, ni d’expérience en RAG, en cadriciels d’agents ou en réglage fin. Si Nadia lisait le CV comme une liste de critères à cocher, cet appel n’aurait pas lieu.

Mais le prochain problème de l’équipe concerne les résumés de réclamations, et Leila a lu des milliers de dossiers de sinistres. Elle a aussi créé un vrai outil que des gens utilisent chaque jour. Marcus a déjà vérifié ses connaissances en règlement de sinistres, alors Nadia se pose une autre question. Leila sait-elle créer des outils? Et peut-elle développer les compétences en ingénierie nécessaires au poste? Nadia note trois points à vérifier :

• Quelle part de l’outil de courriel Leila a-t-elle créée elle-même? Que se passe-t-il quand il échoue?
• « A corrigé une confusion » est un bon point. Comment a-t-elle su que la correction fonctionnait?
• Pour les résumés, sa connaissance du domaine se traduit-elle en décisions d’ingénierie? Et où ses connaissances techniques s’arrêtent-elles?

Termes utilisés dans cette page

• Assurance de dommages (biens et responsabilité civile) : assurance qui couvre les biens, comme les maisons et les voitures, et les dommages que vous causez à autrui.
• Assuré (comme nom) : la personne ou l’entreprise que la police couvre.
• Exclusion : une partie de la police qui précise ce qu’elle ne couvre pas.
• Avenant : une modification à une police standard, par exemple pour ajouter une garantie que le texte de base exclut.
• Subrogation : après avoir indemnisé son assuré, l’assureur tente de récupérer l’argent auprès du responsable du sinistre ou de son assureur.
• Preuve de sinistre : une déclaration signée de l’assuré sur les biens perdus et leur coût. La police ou la loi fixe le délai pour la fournir.
• Provision : l’argent qu’un assureur met de côté pour le coût prévu d’une réclamation.
• LLM (grand modèle de langage) : un modèle qui lit et écrit du texte, comme les modèles derrière les assistants conversationnels.
• RAG (génération augmentée par récupération) : le système trouve d’abord les parties pertinentes des documents, puis donne seulement ces parties au modèle.
• Segment : une de ces parties. Plongement (embedding) : une liste de nombres qui représente le sens d’un texte, pour trouver des textes au sens semblable.
• Jeu d’évaluation (ou jeu de référence) : des exemples réels avec des réponses que des experts ont vérifiées. Vous exécutez le système sur ce jeu pour mesurer la qualité.
• Renseignements personnels (PII en anglais) : des renseignements qui permettent d’identifier une personne. Les renseignements sur la santé comptent parmi les plus sensibles.

L’entrevue

Minutes 0 à 5 : l'ouverture

Nadia(intervieweur) :

Bonjour Leila, merci d’avoir pris le temps. Je suis Nadia, ingénieure principale dans l’équipe Claims Intelligence. J’ai créé la majeure partie de notre extraction à la réception des dossiers.

Leila(personne candidate) :

Bonjour Nadia, enchantée.

Nadia(intervieweur) :

Alors, voici le plan. D’abord, vous me parlez de quelque chose que vous avez créé, et je pose beaucoup de questions. C’est normal. Ensuite, je vous présente un de nos problèmes. À la fin, vous posez vos questions. Ah, et comme l’invitation le disait, pas d’assistants d’IA pour cette étape. Les notes sur papier sont permises. Ça vous va?

Leila(personne candidate) :

Oui, ça va. Pour être honnête, je suis un peu nerveuse. C’est ma première entrevue pour un poste en ingénierie. En règlement de sinistres, c’est généralement moi qui pose les questions.

Nadia(intervieweur) :

Alors vous savez comment ça fonctionne. Je ne cherche pas à vous piéger. Je veux juste comprendre ce que vous avez fait. Commençons.

Minutes 5 à 25 : le projet, puis les questions approfondies

Nadia(intervieweur) :

Alors, choisissez un projet dont vous êtes fière et expliquez-moi ce que vous avez fait.

Leila(personne candidate) :

D’accord. Chez Northgate, mon équipe a une boîte de réception commune pour les sinistres. Environ 140 courriels par jour. Nouveaux sinistres, mises à jour, factures, lettres d’autres assureurs, d’avocats. Quelqu’un devait tous les lire, les classer dans le bon dossier et envoyer un accusé de réception. Ça prenait environ deux heures par jour à un expert en sinistres.

J’ai donc créé un script Python. Toutes les dix minutes, il lit les nouveaux courriels avec l’API Microsoft Graph. Il envoie le texte au LLM approuvé par notre service informatique. Il demande une des sept catégories et le numéro de dossier, s’il y en a un. Ensuite, il prépare un accusé de réception à partir d’un modèle de lettre pour cette catégorie.

Nadia(intervieweur) :

Et la lettre part automatiquement?

Leila(personne candidate) :

Non, non. Rien ne part tout seul. L’expert en sinistres envoie le brouillon ou le modifie. Le service informatique l’a approuvé. L’équipe l’utilise chaque jour depuis… huit mois maintenant, oui.

Nadia(intervieweur) :

Bien. Dans votre CV, vous dites avoir « corrigé une confusion entre les courriels de subrogation et les nouvelles réclamations ». Qu’est-ce qui s’est passé?

Leila(personne candidate) :

Oui. La subrogation va dans les deux sens. D’autres assureurs nous envoient des demandes quand ils pensent que notre assuré a causé leur sinistre. La lettre dit quelque chose comme « notre assuré a subi un dégât d’eau le 3 mars, causé par une fuite du logement de votre assuré au-dessus ».

Nadia(intervieweur) :

Et pour le modèle, ça ressemble à une nouvelle réclamation.

Leila(personne candidate) :

Exactement. Ça se lit comme une nouvelle réclamation. J’ai vérifié 300 courriels à la main. Il y en avait 22 de subrogation, et l’outil en a classé 13 comme « nouvelle réclamation ». C’est une erreur grave. Quelqu’un ouvre un dossier en double. Et la demande a souvent une date limite de réponse, mais elle reste dans la mauvaise file.

Nadia(intervieweur) :

Comment avez-vous corrigé ça?

Leila(personne candidate) :

Deux choses. D’abord, j’ai expliqué la différence dans la requête (prompt), avec trois exemples. Sans les noms, bien sûr. Ensuite, j’ai ajouté une règle dans le code, avant le modèle. Si le domaine de l’expéditeur figure dans une liste d’assureurs et de sociétés de recouvrement, et que le texte dit « votre assuré », le courriel va directement en subrogation.

Nadia(intervieweur) :

Une règle simple.

Leila(personne candidate) :

Oui, rien de passionnant. Mais je sais exactement quand elle s’applique.

Pourquoi cela fonctionne

C’est la partie la plus solide de son projet. Elle vient de sa connaissance du domaine. Leila sait que seule l’autre partie écrit « votre assuré ». Elle sait aussi pourquoi cette erreur coûte si cher. Une personne qui regarde seulement l’exactitude globale pourrait ne jamais remarquer que cette catégorie compte le plus.

Nadia(intervieweur) :

Et après la correction, comment avez-vous su que ça fonctionnait?

Leila(personne candidate) :

J’ai relancé le script sur les 300 courriels. Et ceux de subrogation étaient tous corrects, 22 sur 22.

Nadia(intervieweur) :

Les mêmes 300 courriels dont vous avez tiré les exemples?

Leila(personne candidate) :

Oui… ah. D’accord, je vois. J’ai pris mes trois exemples dans ces courriels, donc évidemment, il les a bien classés.

Nadia(intervieweur) :

Hum hum. Avez-vous fait un test sur d’autres courriels après?

Leila(personne candidate) :

Oui, un mois plus tard, parce que mon gestionnaire l’a demandé. J’ai vérifié 100 nouveaux courriels. Neuf concernaient la subrogation, je pense, et il en a reconnu huit. Celui qu’il a manqué venait d’un avocat, pas d’un assureur. Ma liste de domaines ne l’a donc pas repéré. Et je n’ai jamais vraiment corrigé ça.

Comment Nadia approfondit le sujet

La question de Nadia vérifie une idée de base de la mesure. Quand vous modifiez une requête à partir d’exemples, le score sur ces mêmes exemples paraît meilleur que la réalité. Il vous faut des données de test distinctes, que vous n’avez pas consultées pendant les modifications. Voir Données d’entraînement, de validation et de test. Leila n’a pas utilisé ce terme. Mais elle a vu le problème tout de suite et elle a dit la vérité.

Nadia(intervieweur) :

Merci, c’est honnête. Maintenant, qu’arrive-t-il quand l’appel au modèle échoue?

Leila(personne candidate) :

Vous voulez dire quand il donne la mauvaise catégorie?

Nadia(intervieweur) :

Non, désolée, je n’étais pas claire. Je parle d’un échec de l’appel lui-même. Un délai dépassé, une erreur de l’API.

Leila(personne candidate) :

Ah, d’accord. Il essaie alors trois fois, avec une attente entre les tentatives. Ensuite, le courriel reste « non classé », et l’équipe le traite comme avant. Et si plus de 20 appels échouent dans une journée, je reçois un courriel.

Nadia(intervieweur) :

D’accord. Et si le script plante au milieu d’un lot, est-ce qu’il peut traiter le même courriel deux fois?

Leila(personne candidate) :

Deux fois… je pense que ça va? Je marque chaque courriel dans Outlook après avoir enregistré le brouillon. Hum. Attendez. En fait, non. S’il plante après le brouillon, mais avant le marquage, la prochaine exécution crée un deuxième brouillon. C’est arrivé une fois. Quelqu’un a supprimé le brouillon de trop. Je n’ai jamais vraiment corrigé ça.

Où cela tourne mal

La faille est un plantage entre deux étapes. Dans un outil pour 9 personnes, quelqu’un supprime le brouillon de trop. À 9 000 dossiers par jour, la même faille peut créer des doublons chaque jour. Nadia n’a pas besoin du mot « idempotent » (qu’on peut exécuter deux fois sans risque). Elle veut voir si Leila trouve la faille, et Leila la trouve.

Nadia(intervieweur) :

Qui révise votre code? Et avez-vous des tests?

Leila(personne candidate) :

Personne, vraiment. Le service informatique l’a lu une fois avant de l’approuver, surtout pour la sécurité. Les tests… J’ai ajouté une quinzaine de tests pytest il y a trois mois, surtout pour la règle de subrogation et les modèles de lettres. Avant ça, je testais en exécutant le script et en regardant le résultat.

Nadia(intervieweur) :

D’accord.

Leila(personne candidate) :

Et je dois préciser que je n’ai jamais travaillé avec d’autres personnes sur une base de code.

Nadia(intervieweur) :

C’est utile à savoir, merci. Bon, passons à notre problème.

Minutes 25 à 48 : le problème de Quillfield

Nadia(intervieweur) :

Alors, c’est un vrai problème chez nous. Un dossier de sinistre arrive. Il contient de 20 à 60 pages : formulaires numérisés, notes de l’expert en sinistres, courriels, photos, estimation d’un entrepreneur. Les experts nous disent qu’ils passent environ 40 minutes à lire un dossier avant de pouvoir agir.

Leila(personne candidate) :

Oui, quarante minutes, ça me paraît juste.

Nadia(intervieweur) :

Nous voulons leur donner un brouillon de résumé d’une page. Les faits importants, les questions en suspens et les éléments manquants. Comment aborderiez-vous ça?

Leila(personne candidate) :

D’accord. Avant de concevoir quoi que ce soit… les quarante minutes de qui? De l’expert qui vient de recevoir le dossier, ou de quelqu’un d’autre? Et est-ce qu’on regroupe l’habitation et l’automobile? Parce qu’un fait important pour un dégât d’eau ne l’est pas forcément pour un accident automobile avec blessure.

Nadia(intervieweur) :

Les sinistres habitation d’abord, avec un assureur pour le projet pilote. Je vois ça ainsi : l’expert responsable ouvre le dossier, lit tout le résumé et économise presque les 40 minutes.

Leila(personne candidate) :

Hum. Est-ce que je peux être un peu en désaccord?

Nadia(intervieweur) :

Bien sûr, allez-y.

Leila(personne candidate) :

Les experts ne le liront pas du début à la fin. Et il ne remplacera pas le dossier, pas pour ce qui touche à l’argent. On nous forme à consulter la source, et on nous audite là-dessus. Si j’inscris un paiement au dossier, mon superviseur demande « où est-ce que c’est écrit? ». Et « le résumé le disait » n’est pas une réponse.

Nadia(intervieweur) :

D’accord. Alors comment l’utiliseraient-ils?

Leila(personne candidate) :

Comme une carte. Un bon expert va directement aux éléments qui pourraient empêcher la couverture du sinistre, et à ce qui manque. Ensuite, il ouvre ces pages. Donc on ne passe pas de 40 minutes à zéro. C’est plutôt… 40 minutes de recherche qui deviennent peut-être 15 minutes de vérification.

Nadia(intervieweur) :

Hum hum.

Leila(personne candidate) :

Et honnêtement, je pense qu’il sera surtout utile à la deuxième personne qui lit le dossier. Les dossiers passent constamment d’une personne à l’autre. Quelqu’un part en vacances, un sinistre passe à l’équipe des sinistres majeurs, un superviseur révise la provision. Cette personne lit le dossier sans aucun contexte. C’est là qu’un résumé fait gagner le plus de temps.

Nadia(intervieweur) :

Hum. D’accord, c’est une correction justifiée. Nos experts en sinistres ont dit quelque chose de semblable sur les transferts de dossiers. Je n’ai pas fait le lien avec la conception. Si c’est une carte, la mise en page et les liens vers les pages comptent plus que de belles phrases. Je vais le noter.

Bien exprimer un désaccord

Nadia supposait que les experts liraient tout le résumé et économiseraient presque les 40 minutes. Leila la corrige à partir de ce qu’elle a observé, pas d’une opinion. Elle explique ensuite ce que cela signifie pour la conception. Elle ajoute aussi une nouvelle idée : la deuxième personne qui lit le dossier. Nadia l’accepte, et la conception s’améliore. Voir Les personnes qui mènent les entrevues n’ont pas toujours raison.

Nadia(intervieweur) :

Alors, avec ça en tête, que mettez-vous sur la page?

Leila(personne candidate) :

Pas un récit en texte libre. Je ferais trois blocs. D’abord, les faits, chacun avec sa page. Vous extrayez déjà 32 champs, n’est-ce pas? Je partirais donc de ces champs.

Nadia(intervieweur) :

Exact.

Leila(personne candidate) :

Ensuite, ce qui manque. Un dossier complet de dégât d’eau contient le rapport du plombier sur la cause, des photos, la liste des biens et la preuve de sinistre. C’est presque une liste de vérification pour chaque type de sinistre. Ce n’est même pas de l’IA.

Nadia(intervieweur) :

Et le troisième?

Leila(personne candidate) :

Le troisième est le plus important pour moi : les contradictions. Par exemple, la déclaration initiale dit que la fuite a commencé hier. Mais l’estimation de l’entrepreneur mentionne de la moisissure et un sous-plancher pourri. Ce n’est pas une fuite d’un jour. La plupart des polices habitation couvrent les dégâts d’eau soudains et accidentels. Elles excluent les fuites qui durent. Ce seul détail peut donc changer la couverture.

Nadia(intervieweur) :

Le résumé le dirait-il? Quelque chose comme « probablement exclu »?

Leila(personne candidate) :

Non, jamais. La couverture, c’est la décision de l’expert en sinistres. Il devrait dire « Fuite graduelle possible, voir les pages 31 et 44. Vérifier l’exclusion. » Une question, pas une réponse.

Et honnêtement, ce qui est omis me fait plus peur que ce qui est faux. Une mauvaise date, l’expert va la voir. Mais si le résumé omet une exclusion, un sinistre antérieur dans le même sous-sol ou une échéance comme la preuve de sinistre… personne ne cherche quelque chose dont il ignore l’existence.

Pourquoi c'est la réponse la plus solide de la journée

Leila transforme sa connaissance du domaine en décisions de conception :

• Chaque fait renvoie à sa page.
• Les éléments manquants forment une liste de vérification, car une liste est plus facile à vérifier qu’un texte libre.
• Les contradictions passent en premier, car elles soulèvent des questions de couverture.
• Le résumé ne formule jamais de conclusion sur la couverture.

Et elle nomme la pire erreur : l’omission d’un élément important.

Nadia(intervieweur) :

Comment mesureriez-vous les omissions?

Leila(personne candidate) :

Hum. Laissez-moi réfléchir. Je demanderais à des spécialistes des sinistres de prendre de vrais dossiers. Pour chacun, ils noteraient les éléments qui doivent figurer sur la page. Pas un résumé parfait, seulement les éléments indispensables.

Nadia(intervieweur) :

Hum hum.

Leila(personne candidate) :

Ensuite, pour chaque résumé généré, on compte. Quels éléments indispensables sont présents, lesquels manquent, et quelles affirmations ne sont appuyées par aucune page. Les omissions comptent le plus. Combien de dossiers… je ne sais pas. Peut-être cent? Répartis entre les types de sinistres.

Nadia(intervieweur) :

C’est proche de ce qu’on ferait. Bon, maintenant la partie technique. Pour la question de l’exclusion, le modèle a aussi besoin de la police. C’est 40 pages, plus les avenants. Dans notre assistant pour les polices, nous utilisons la génération augmentée par récupération, ou RAG, pour ça. Comment donneriez-vous les bonnes clauses au modèle?

Leila(personne candidate) :

J’ai seulement fait du RAG dans un tutoriel, alors… Mais je découperais la police par clause, pas tous les 500 mots. Parce qu’une exclusion coupée en deux, c’est dangereux. « Nous ne couvrons pas les dégâts d’eau » est dans un segment. Et « sauf s’ils sont causés par une fuite d’eau soudaine et accidentelle » est dans le suivant. Si le modèle reçoit seulement le premier segment, il dit le contraire de la police.

Nadia(intervieweur) :

Bien. Alors voici notre vrai problème. Dans le projet pilote, l’assistant cite parfois la police de base et manque l’avenant qui a modifié la clause. Comment corrigeriez-vous ça?

Leila(personne candidate) :

Ah, je connais ce problème du côté des sinistres. Le refoulement d’égout est le cas typique. Le texte de base l’exclut. L’assuré ajoute cette couverture par un avenant, souvent avec sa propre limite. Si le système lit seulement la police de base, il dit « exclu ». Et l’expert refuse une réclamation qui est couverte.

Nadia(intervieweur) :

Exact. Et techniquement?

Leila(personne candidate) :

Techniquement… là, je fais une supposition. Pourriez-vous rattacher chaque avenant à la clause qu’il modifie? Comme une étiquette sur le segment?

Nadia(intervieweur) :

Peut-être. Mais comment la recherche trouverait-elle l’avenant? Qu’est-ce qui fait qu’un segment « correspond » à la question?

Leila(personne candidate) :

Je pense qu’on transforme le texte en nombres, des plongements (embeddings). Puis on trouve les segments avec des nombres proches? Après ça, honnêtement, je ne sais pas comment il les classe, ni pourquoi il préférerait la clause de base. Mes connaissances s’arrêtent là. Avant de faire d’autres suppositions, je regarderais ce qu’il récupère réellement pour quelques questions qui échouent.

Nadia(intervieweur) :

C’est la bonne première étape. Arrêtons-nous là. Dernier sujet : certains de ces dossiers concernent des blessures.

Leila(personne candidate) :

Oui, je voulais poser une question là-dessus. Des rapports médicaux, parfois des antécédents de santé mentale. Dans mon équipe, seuls l’expert responsable du dossier et son superviseur les voient. Si plus de personnes peuvent voir le résumé que le dossier, un diagnostic en première page pose un problème de confidentialité.

Nadia(intervieweur) :

Alors que feriez-vous?

Leila(personne candidate) :

Le résumé suit les mêmes règles d’accès que les documents. Et il dit « documents médicaux reçus, pages 12 à 19 », sans les détails.

Une réponse plus solide à la limite de ses connaissances

Leila a bien réagi à la limite de ses connaissances. Elle a dit ce qu’elle savait, où ses connaissances s’arrêtaient, et proposé une première étape. Mais elle n’avait pas besoin d’en savoir plus sur la récupération pour aller plus loin. Elle pouvait raisonner à partir du travail d’un expert en sinistres :

« Hum, qu’est-ce que je fais comme experte en sinistres? Je prends d’abord la page des déclarations. Elle énumère tous les avenants de la police pour cette période. Est-ce que le système peut faire la même chose? Trouver les déclarations pour la date du sinistre et toujours placer ces avenants à côté des clauses de base. La recherche sert alors seulement à trouver le texte de base. Je testerais ça sur les questions du projet pilote où l’assistant a manqué un avenant. »

Cette réponse remplace un problème de recherche par une consultation qui donne toujours le même résultat. Un ingénieur expérimenté la prendrait au sérieux.

Nadia a ensuite posé une question sur le volume. À 9 000 dossiers par jour, faut-il créer le résumé à la réception ou quand un expert ouvre le dossier? Leila a raisonné à partir du travail : les documents continuent d’arriver. Elle créerait donc un nouveau résumé à l’arrivée de nouveaux documents. Elle ne pouvait pas estimer le coût et l’a dit.

Nadia donne ensuite la dernière partie de l’appel à Leila.

Minutes 48 à 57 : les questions de Leila

Leila(personne candidate) :

J’en ai quelques-unes. D’abord : qui décide de ce qu’est un résumé correct? Les deux experts en sinistres, les experts de l’assureur du projet pilote ou l’équipe d’ingénierie? Parce que je pense que ces trois groupes ne seront pas d’accord.

Nadia(intervieweur) :

La réponse honnête? Pour l’instant, personne, pas officiellement. Nous n’avons pas encore de cadre d’évaluation commun. C’est la phrase « aider à définir notre stratégie d’évaluation » dans l’offre, et c’est urgent. Et nos deux experts ont environ quatre heures par semaine à eux deux. Au total. La majeure partie sert à l’échantillon hebdomadaire des dossiers reçus.

Leila(personne candidate) :

Quatre heures, pour les deux? D’accord. Alors leur temps est ce qui coûte le plus cher dans le projet, et je le protégerais. Deuxième question : qui réviserait mon code? Je n’ai jamais eu de révision.

Nadia(intervieweur) :

Un autre ingénieur révise chaque modification. Les miennes aussi. Pour le travail en binôme pendant les premiers mois, c’est une question pour Marcus. Posez-la-lui directement.

Leila(personne candidate) :

D’accord, je le ferai. Et quand un expert du projet pilote trouve le résumé incorrect, où va ce signalement aujourd’hui?

Nadia(intervieweur) :

Hum. Honnêtement, aujourd’hui, c’est un courriel au responsable produit. Il n’y a pas encore de bouton à l’écran.

Leila(personne candidate) :

D’accord. Et, euh, la dernière. Pensez-vous que mes compétences techniques suffisent pour ce poste?

Nadia(intervieweur) :

Je ne peux pas vous donner de décision ici. Ce que je peux dire, c’est ceci : j’ai découvert vos forces et vos lacunes. Je vais noter les deux honnêtement.

Les bonnes questions

Les premières questions de Leila portent sur le travail. Chaque réponse lui apprend quelque chose de concret :

• L’évaluation n’est pas encore en place.
• Les experts ont très peu de temps.
• Les commentaires des utilisateurs n’ont pas encore de canal.

C’est l’entrevue comme conversation dans les deux sens.

La question moins utile

« Pensez-vous que mes compétences techniques suffisent? » demande à la personne qui mène l’entrevue de rassurer la candidate. Nadia ne peut pas répondre, donc Leila n’apprend rien. Une meilleure question donne de l’information utile sur le poste : « Si je rejoignais l’équipe, que voudriez-vous me voir faire seule après six mois? »

Minutes 57 à 60 : la conclusion

Nadia(intervieweur) :

Merci, Leila, j’ai apprécié cette discussion. La prochaine étape est une entrevue de conception de systèmes avec Owen. Puis une conversation avec Sofia, qui dirige les opérations de règlement des sinistres. Hannah vous contactera cette semaine.

Leila(personne candidate) :

Merci. Et merci pour la question sur les mêmes 300 courriels. Je vais corriger ça lundi.

Après l’appel : les notes de Nadia

Nadia rédige ses notes le même après-midi, en les comparant à l’offre d’emploi.

Leila Haddad, entrevue technique approfondie

• Domaine et définition du problème : preuves solides. Meilleure définition du problème des résumés jusqu’ici : faits avec pages, liste des éléments manquants, contradictions, « ne jamais affirmer la couverture ». Elle a corrigé mon hypothèse sur l’utilisation des résumés par les experts en sinistres. Elle avait raison.
• Évaluation : quelques preuves. Elle a évalué son outil à la main et trouvé elle-même l’erreur coûteuse. Elle a ajusté et évalué l’outil sur le même jeu de données. Elle ne l’a remarqué qu’à ma question. Bon réflexe : les omissions d’abord.
• Python et production : quelques preuves. Un script utilisé chaque jour depuis 8 mois, avec nouvelles tentatives et alertes. Aucune révision de code; tests récents; un bogue connu de doublons qu’elle n’a pas corrigé.
• RAG et récupération : aucune preuve au-delà des bases. Elle connaît la RAG grâce à un tutoriel; découpage par clause pour une bonne raison. Elle ne savait pas comment fonctionne le classement et l’a dit clairement.
• Passage à l’échelle et exploitation : aucune preuve. Bon raisonnement à partir du travail réel. Elle n’a pas pu estimer le coût.
• Confidentialité : preuves solides. Elle a soulevé elle-même la question des renseignements de santé, avec la bonne règle : le résumé suit les règles d’accès des documents.

Recommandation : oui, avec un plan. Elle ne répond pas aux critères « 4 ans ou plus » et « 2 ans ou plus avec des LLM en production ». Mais elle apporte les compétences les plus difficiles à trouver, et elle reconnaît honnêtement ses limites. La jumeler avec un ingénieur principal pendant trois mois. Lui confier l’évaluation des résumés dès la première semaine. Nous pouvons combler ses lacunes par la formation. Nous ne pouvons pas lui enseigner son jugement sur les sinistres.

La suite

L’entrevue de conception de systèmes avec Owen a donné des résultats mitigés. Leila a conçu un flux logique, mais les files d’attente, le traitement par lots et les coûts lui ont posé problème. Le volume était de 9 000 dossiers par jour. La discussion sur les valeurs avec Sofia a donné un oui convaincu. Sofia est une ancienne experte en sinistres. Elle a écrit : « Elle pense à la personne assurée derrière chaque dossier. Et elle saura dire non aux ingénieurs. »

Lors du bilan, Owen était inquiet. Il pensait que les autres ingénieurs devraient faire son travail d’infrastructure pendant un an. Nadia a répondu que l’équipe avait déjà de solides ingénieurs en infrastructure. Mais personne ne connaissait assez les sinistres pour décider, avec les experts en sinistres, du contenu obligatoire des résumés. Il y avait un seul poste vacant et plusieurs finalistes solides. L’équipe a choisi Leila. Marcus a fait une offre dans le bas de la fourchette : 145 000 $ CA, plus prime et participation au capital. Le plan : trois mois de jumelage avec un ingénieur principal. Les gardes commenceraient seulement après deux rotations d’observation, avec un bilan après six mois.

Elle a demandé 160 000 $ CA, car elle serait responsable des listes d’éléments obligatoires et des exigences des résumés avec les experts en sinistres. Elle a aussi demandé d’inclure le plan de jumelage dans sa lettre d’offre. Marcus a proposé 152 000 $ CA et le plan par écrit. Elle a accepté.

C’est une issue réaliste, pas une promesse. Une autre entreprise aurait pu refuser à cause des années d’expérience demandées dans l’offre. La chance joue aussi un rôle.

Ce qu’il faut retenir

• La connaissance du domaine fait la différence quand elle guide la conception. Leila n’a pas seulement dit « je connais les sinistres ». Elle a précisé ce qui doit figurer sur la page, ce qui ne doit jamais y figurer, et pourquoi. Chaque point a changé le système.
• Vous pouvez corriger la personne qui vous interroge sur votre domaine. Appuyez-vous sur vos observations, pas sur vos croyances. Expliquez ce que cela implique pour la conception.
• Votre projet sera examiné comme un vrai travail d’ingénierie. Préparez-vous à expliquer comment vous l’avez évalué, ce qui arrive en cas d’échec et qui révise le code.
• Posez des questions sur le travail. Les questions de Leila lui ont révélé trois vrais problèmes : aucun cadre d’évaluation, très peu de disponibilité des experts et aucun canal de rétroaction.
• Connaître vos limites n’est pas un échec. Leila a dit « mes connaissances s’arrêtent là » et proposé une première étape. Comme elle l’a dit clairement, Nadia pouvait faire confiance au reste de ses propos.

Si votre profil ressemble à celui de Leila

1. Créez un outil pour votre travail réel et évaluez-le. Vérifiez-le sur des cas réels et comptez les erreurs par type, pas seulement au total. Trouvez l’erreur qui coûte le plus cher dans votre domaine.
2. Gardez des données de test séparées. Ne prenez pas d’exemples de requêtes (prompts) dans les cas qui servent à l’évaluation. Après chaque changement de requête ou de modèle, utilisez les mêmes cas vérifiés. Consultez Les métriques de classification.
3. Comblez les lacunes en ingénierie vérifiées en premier dans les entrevues. Écrivez des tests (Des tests ciblés), gérez les échecs (Exceptions et journalisation) et faites réviser votre code (Lire et réviser les différences). Si personne au travail ne peut le réviser, publiez une copie sans données privées. Demandez à un développeur d’une communauté de la réviser.
4. Approfondissez vos connaissances un niveau au-delà de votre projet. Si vous avez appelé une API de LLM, apprenez comment la récupération trouve et classe les segments, et comment l’évaluer. Vous pourrez alors expliquer clairement vos limites.
5. Transformez vos récits du domaine en décisions de conception. Pour chaque récit, décrivez l’erreur, pourquoi elle coûte cher et ce que le système devrait faire pour y remédier. Votre expérience est une longueur d’avance et La connaissance du domaine en pratique vous aident à les écrire. Expliquer vos décisions vous aide à les dire à voix haute.