Fonctionnalités générées par l’IA : préserver la cohérence du produit

Évaluer une fonctionnalité générée par l’IA consiste à vérifier qu’elle résout un véritable problème client, respecte un périmètre précis, fonctionne sur l’ensemble du parcours et relève d’une personne chargée d’en examiner le résultat. La vérification technique reste nécessaire. Ces questions vous aident à décider si la modification a sa place dans le produit avant sa mise en production.

Un agent peut produire une démonstration convaincante avant que vous ayez tranché. Vous pouvez cliquer sur le nouveau bouton, examiner le code et valider les tests. Pourtant, vous ajoutez peut-être une deuxième manière d’effectuer une tâche existante, un réglage incompréhensible ou une étape qui reporte du travail sur quelqu’un d’autre.

Dans Quelqu’un derrière le logiciel, publié le 15 octobre, Karri Saarinen, cofondateur de Linear, s’inquiète de modifications raisonnables prises isolément, mais susceptibles d’affaiblir une vision commune du produit. L’essai a suscité une discussion animée sur Hacker News. Il exprime le point de vue d’un praticien ; il ne démontre pas que les agents dégradent généralement les produits.

La question utile est de savoir quoi examiner lorsque l’implémentation arrive avant la décision produit. Nous proposons un processus de revue en quatre points de décision. Il s’inspire des conseils de YC sur la compréhension des besoins clients et des pratiques de projet décrites dans Shape Up, de Basecamp. Leur combinaison constitue notre recommandation : aucun taux de réussite n’a été mesuré et nous ne prétendons pas qu’elle a été validée scientifiquement.

Pourquoi une fonctionnalité opérationnelle peut-elle affaiblir un produit ?

Une fonctionnalité peut respecter ses spécifications tout en compliquant la tâche dans laquelle elle s’insère. La cohérence du produit suppose que ses différentes parties permettent d’accomplir une tâche de manière compréhensible, y compris avant et après la nouvelle interaction.

Imaginez un raccourci pour modifier l’horaire d’un entretien. Il fonctionne. Mais le candidat reçoit un message différent de celui que voit le recruteur, et un ancien lien renvoie toujours à l’horaire précédent. Chaque écran peut sembler logique alors que, dans l’ensemble, personne ne sait plus quel rendez-vous fait foi.

Saarinen rattache le jugement produit à l’expérience, aux échanges avec les clients et à l’attention portée à l’articulation des différents éléments. La discussion devient alors plus concrète qu’une simple impression favorable. Demandez-vous quelles attentes existantes la modification bouscule et si les personnes concernées peuvent toujours terminer leur tâche.

Cette question s’applique au travail d’une personne, d’un agent ou des deux. C’est la proposition de modification du produit qui justifie la revue. L’auteur du code ne détermine pas si elle mérite d’être retenue.

Adaptez la revue à l’ampleur du changement. Une correction de libellé peut se justifier par une courte explication et une capture d’écran. Un nouveau parcours de planification nécessite des éléments sur les interactions qu’il modifie. Les quatre points suivants servent à prendre cette décision, sans créer un comité de validation pour chaque retouche.

Quel problème client cette modification résout-elle ?

Partez d’une situation réelle où un utilisateur a rencontré une difficulté. Notez ce qu’il cherchait à faire, l’endroit où il a été bloqué et la manière dont il s’en est sorti avec le produit actuel.

Dans le compte rendu de Startup School et sa transcription publiés par YC, Eric Migicovsky recommande d’interroger la personne sur une difficulté rencontrée par le passé et sur les solutions déjà essayées. Ces questions apportent davantage qu’une réaction à la solution que vous proposez.

Pour la revue, joignez un échange avec l’assistance, une séance d’observation ou un exemple client clairement décrit. Distinguez le constat de votre interprétation. « Le recruteur a recopié le nouvel horaire dans deux messages » décrit un comportement. « Il nous faut un assistant de planification fondé sur l’IA » propose une solution au périmètre beaucoup plus vaste.

Identifiez la personne concernée avec la précision que la tâche exige. Un candidat qui modifie sa propre réservation n’a pas les mêmes besoins qu’un recruteur chargé de coordonner plusieurs personnes pour un entretien. Les désigner tous deux comme « l’utilisateur » peut masquer le passage de relais que vous devez comprendre.

Les éléments recueillis peuvent justifier une amélioration ciblée sans éclaircir tout le potentiel du sujet. Une situation client peut révéler une interaction déroutante ; elle ne permet pas d’établir la fréquence du problème sur l’ensemble du marché. Dites ce que vous savez, ce que vous en déduisez et ce qui reste sans réponse.

Même si la fonctionnalité est née d’une démonstration, vous pouvez encore mener cette enquête. Observez quelqu’un effectuer la tâche actuelle avant de lui présenter la modification. Vous découvrirez peut-être qu’un texte plus clair ou un lien existant suffit. Vous pourrez aussi repérer un besoin plus profond que la démonstration avait manqué.

Point de décision : pouvez-vous décrire la difficulté du client sans évoquer la fonctionnalité ? Si la réponse revient uniquement à décrire ce que l’agent a construit, examinez le problème avant d’étendre l’implémentation.

Quel arbitrage permet de maîtriser le périmètre ?

Définissez le résultat utile et la complexité que vous acceptez. Précisez aussi une exclusion pour donner une limite à la revue.

Le chapitre de Shape Up consacré aux limites du projet explique comment fixer l’investissement que l’on est prêt à consacrer à un projet, puis circonscrire le problème en conséquence. Son exemple de calendrier distingue le besoin de voir les créneaux disponibles de l’idée, bien plus vaste, de construire toutes les fonctions possibles d’un calendrier.

Faites la même distinction lors de la revue. « Aider un candidat à trouver le parcours existant pour déplacer un rendez-vous » définit un résultat circonscrit. « Simplifier toute la planification » laisse la porte ouverte à de nouveaux calendriers, droits d’accès, rappels, préférences et exceptions, sans préciser ce qui compte maintenant.

Consignez la solution de rechange envisagée. Pourriez-vous améliorer le parcours actuel, supprimer une étape déroutante ou corriger le message qui y conduit ? Face au produit inchangé, la nouvelle fonctionnalité a facilement l’avantage. La comparer à une correction plus modeste et utile rend l’arbitrage visible.

Indiquez ensuite ce que vous écartez. Dans l’exemple de planification, vous pourriez exclure toute modification de l’affectation des intervieweurs ou des règles de notification. Cette exclusion devient utile lorsqu’une idée voisine et séduisante apparaît pendant le développement : vous pouvez alors décider si les nouveaux éléments justifient de revoir le périmètre.

Pensez également au coût à long terme. Il faudra expliquer la fonctionnalité, maintenir ses différents états, traduire ses messages et gérer ses échecs. Chaque bouton ne nécessite pas un modèle financier hypothétique. En revanche, vous devez repérer les raccourcis qui créent une interaction supplémentaire dont l’équipe devra préserver la cohérence.

Point de décision : pouvez-vous expliquer pourquoi cette version mérite d’être maintenue plutôt que la solution plus modeste ? Si la réponse reste floue, réduisez ou retravaillez la proposition. Une implémentation opérationnelle peut encore vous apprendre quelque chose, même si vous décidez de ne pas la publier.

Le parcours complet reste-t-il cohérent ?

Essayez la modification dans une tâche réelle, en vérifiant les données sauvegardées et l’expérience de la personne suivante. Un écran soigné ou un composant isolé ne montre pas toute l’interaction.

Le chapitre de Shape Up consacré à la réalisation d’un premier ensemble utilisable recommande d’intégrer une portion fonctionnelle que l’on puisse essayer. Appliquez ce principe à la revue : suivez la tâche depuis son déclenchement jusqu’au passage de relais qu’elle entraîne.

Pour une modification de réservation, commencez là où le candidat reçoit effectivement l’invitation. Suivez le lien, choisissez un horaire, sauvegardez-le et revenez à la réservation. Examinez ensuite ce que voit le recruteur et les messages reçus par chaque participant. Vérifiez que le résultat persiste après avoir quitté la page.

Choisissez les cas délicats en fonction du changement. Un créneau peut devenir indisponible avant la confirmation. Un candidat peut rouvrir un ancien lien. Un intervieweur peut annuler alors qu’une autre personne a encore la page ouverte. Un parcours de vérification ne peut épuiser tous les cas, mais il peut faire apparaître les hypothèses à vérifier techniquement.

Examinez aussi ce qui entoure la nouvelle interaction. Le parcours utilise-t-il des libellés familiers ? Peut-on reprendre la tâche après une erreur ? La personne concernée peut-elle effectuer l’action sur un petit écran ? L’accès dépend-il toujours du bon compte ou de l’autorisation associée à la réservation ?

Décrivez précisément la portée des preuves. Une vidéo établit ce qui s’est passé sur le parcours filmé. Les tests automatisés établissent un comportement dans les limites de leurs assertions et de leur configuration. Aucun des deux ne permet d’affirmer que le produit entier est correct.

La démarche rejoint celle qui consiste à faire tester les consignes d’un exercice de code à domicile par une personne qui les découvre : observer quelqu’un suivre le parcours réel peut révéler des lacunes devenues invisibles à son auteur. Ici, la décision porte aussi sur la place de la fonctionnalité dans le reste du produit.

Point de décision : la personne visée peut-elle accomplir la tâche promise, et la suivante peut-elle comprendre le résultat ? Si un passage de relais échoue, corrigez-le ou réduisez la promesse avant la mise en production.

Qui répond du résultat après la mise en production ?

Désignez une personne responsable de la modification et une observation précise à effectuer après sa publication. Cette responsabilité doit aller jusqu’à vérifier si le changement a été utile.

Dans Confier la responsabilité, Shape Up décrit l’attribution d’un projet entier, au périmètre défini, à une équipe qui organise elle-même ses tâches. Cela favorise l’autonomie dans un cadre clair. Le fondateur n’a pas besoin de valider chaque choix d’implémentation pour préserver la cohérence du produit.

Nommez la personne capable d’expliquer la décision, de réunir les interlocuteurs concernés et d’agir en fonction de la suite. Il peut s’agir d’un responsable produit, d’un concepteur, d’un ingénieur ou du fondateur. L’équipe peut se répartir le travail tout en gardant un interlocuteur clairement identifié.

Choisissez une observation liée au problème initial. Si les candidats ne trouvaient pas comment déplacer une réservation, vérifiez s’ils y parviennent désormais et si les échanges avec l’assistance évoluent sur ce sujet. Les clics sur le nouveau bouton ne suffisent pas à répondre à la question de départ.

Pour un produit peu utilisé, un échange direct avec les clients concernés peut être plus instructif qu’un tableau de bord. Sur les parcours plus fréquentés, vous pouvez aussi examiner les événements de réussite et d’échec. Dans les deux cas, évitez d’attribuer au changement un effet observé après sa publication si d’autres conditions ont également évolué.

Décidez ce qui justifierait une nouvelle modification ou un retrait. Le raccourci peut créer de la confusion, doubler un parcours existant ou reporter le travail de coordination sur les recruteurs. Ce sont des raisons de réexaminer la décision produit, même si l’implémentation reste techniquement correcte.

Si vous évaluez la rentabilité des agents, traitez aussi cette question explicitement. Le coût par résultat accepté concerne l’économie du projet pilote. La revue proposée ici vise à déterminer si ce résultat précis mérite d’être accepté.

Point de décision : qui reviendra sur le problème client initial, et qu’examinera cette personne ? Attribuez cette responsabilité avant la mise en production pour que la question ne disparaisse pas après le lancement.

Appliquez les quatre points à une modification de réservation

Prenons une proposition hypothétique : un agent ajoute un bouton bien visible pour déplacer le rendez-vous sur une page de confirmation d’entretien. Il s’agit d’un exemple détaillé, pas du récit d’un incident dans Kit ni de l’annonce d’une fonctionnalité.

Vous partez d’un échange avec un client qui décrit sa difficulté à trouver le parcours existant. La proposition peut résoudre ce problème. Elle ne démontre pas encore la nécessité d’un nouveau mécanisme de planification.

Pour le périmètre, comparez le bouton mis en évidence à une meilleure présentation du lien existant. Supposons que les deux conduisent au même parcours de modification de réservation. Vous pouvez alors évaluer la facilité à le trouver sans revoir simultanément la sélection des horaires disponibles ou des participants. Consignez ce choix dans la description de la revue.

Pour la cohérence du parcours, suivez une modification réussie puis une tentative qui échoue. Examinez la réservation sauvegardée, ce que voit le candidat à son retour, la vue du recruteur et les notifications. Vérifiez ce qu’affiche une ancienne invitation après le changement d’horaire. Un bouton qui mène à la bonne page ne couvre que la première partie de cette revue.

Ces dépendances sont concrètes dans le code de planification actuel de Kit. La modification d’une réservation vérifie l’horaire, l’état de la réservation ainsi que la disponibilité de l’hôte et des participants, met à jour la réservation sauvegardée et le numéro de séquence du calendrier, puis place les notifications en file d’attente. Cette description porte sur les responsabilités de l’implémentation ; elle ne garantit pas la réception de chaque message externe. Elle explique pourquoi une modification apparemment modeste nécessite de regarder l’ensemble de la tâche.

Pour la responsabilité, précisez qui examinera les tentatives suivantes et les retours associés. Cette personne doit savoir si la difficulté initiale du candidat a été résolue et si la nouvelle visibilité du bouton crée un autre problème, par exemple l’attente de pouvoir modifier une réservation qui ne peut plus l’être.

La fiche de revue peut rester concise :

Vous pouvez décider d’accepter la proposition, d’en réduire le périmètre, d’enquêter ou de la refuser. Une note chiffrée suggérerait une précision que ces questions n’ont pas. Lorsque vous suspendez une modification, indiquez les éléments manquants et l’action à mener pour que l’équipe puisse trancher.

Appliquez la même rigueur à votre parcours de recrutement

Le recrutement rend la cohérence du produit tangible : une action du candidat modifie ce que l’équipe doit faire ensuite. Horaires d’entretien, progression dans les étapes, attentes des participants et messages doivent concorder pour que le processus soit compréhensible.

Kit propose des parcours de recrutement et de planification dans lesquels ces liens comptent. Il ne fournit pas les points de décision proposés ici pour la revue produit, ne valide pas les recherches auprès des clients et ne certifie pas les fonctionnalités produites par des agents. Votre équipe reste responsable du choix des modifications et de la vérification de leurs effets.

Avant d’accepter la prochaine fonctionnalité, consignez le problème client, l’arbitrage sur le périmètre, le parcours complet et la personne responsable. Réunissez des éléments proportionnés au changement, puis prenez la décision. Si vous cherchez un parcours de recrutement pour votre startup, vous pouvez essayer Kit et examiner comment ses interactions côté candidat et côté équipe s’intègrent à votre processus.