N’essayez pas d’éviter, par l’ingénierie, le fait d’écouter ce que disent les gens

• Dans le développement logiciel, la difficulté centrale n’est pas tant le manque de conversation que le manque d’écoute ; chercher à résoudre cela en le reformulant avec des termes comme framework ou system revient à contourner l’écoute réellement nécessaire
• Exécuter exactement la demande de quelqu’un n’est pas la même chose que comprendre son besoin réel, et l’effet d’expertise ainsi que la dichotomie technical / non-technical conduisent à passer à côté des connaissances et du contexte de l’autre
• Supposer que tout le monde dispose de la même énergie, des mêmes compétences et des mêmes moyens financiers, ou généraliser à tout un groupe les caractéristiques d’une seule personne, empêche de saisir correctement les contraintes et critères de jugement propres à chacun
• Les personnes et les organisations évoluent selon le temps, le rôle, le stress et la dynamique de groupe, et ce qui est dit ne correspond pas toujours à ce qui est réellement pensé ; des exigences figées se désalignent donc facilement avec la fabrication logicielle
• L’échec de l’écoute fait manquer les insights les plus précieux, ce qui entraîne la perte d’opportunités de revenus et d’avantages concurrentiels, ainsi qu’une hausse de la tech debt due à l’accumulation des malentendus

---

Argument central

• Dans le développement logiciel, le problème fondamental n’est pas tant l’absence de dialogue entre les personnes que le manque d’écoute, et vouloir le résoudre en le reformulant avec des termes comme framework ou system est une manière d’éviter le vrai travail à faire
• Les designers et responsables produit tentent de traduire les échanges avec les gens dans des formulations plus faciles à accepter pour l’engineering, mais plus qu’un meilleur système, ce qu’il faut, c’est écouter réellement ce que disent les personnes
• En partant de l’idée qu’il est plus difficile d’écouter ce que disent les gens que de simplement parler avec eux, l’article récapitule les pièges typiques qui empêchent cette écoute

Pièges typiques qui empêchent d’écouter

• Faire ce qui est demandé n’est pas la même chose qu’écouter

  • Exécuter exactement ce qu’une personne dit vouloir n’est pas équivalent au fait d’écouter son besoin réel
  • Parmi les approches existantes sur ce sujet, mention de Jobs To Be Done, Outcome Driven Innovation et, côté UX, de l’empathy mapping

• L’effet d’expertise fait sous-estimer son propre point de vue

  • Lorsqu’on a longtemps étudié un domaine donné, il devient facile de partir du principe que « cela, tout le monde le sait »
  • Même si l’autre est expert de son domaine, il ne possède pas forcément les mêmes connaissances ; en revanche, il peut avoir d’autres savoirs
  • Pour bien écouter, il faut mieux comprendre ce que l’autre sait

• Considérer technical comme une catégorie unique

  • C’est un piège particulièrement fréquent chez les développeurs logiciels : technical n’est pas une propriété unique, mais un large spectre de domaines de connaissance hétérogènes
  • Voir les gens à travers la dichotomie « technical / non-technical » fait perdre des insights et augmente le risque de mal écouter

• Supposer que tout le monde dispose des mêmes ressources

  • Penser que tout le monde a la même énergie, les mêmes compétences et la même marge financière conduit à de mauvaises évaluations
  • Même des personnes ayant la même santé peuvent gérer leur situation différemment ou ne pas être réellement capables des mêmes actions
  • Il existe des différences entre les personnes à l’aise en mathématiques, celles fortes dans d’autres compétences, ou celles qui agissent de façon plus prudente parce qu’elles ont moins d’argent ou moins de marge de manœuvre

• Généraliser à un groupe entier les caractéristiques d’une seule personne

  • Avoir rencontré une personne avec une certaine caractéristique ne signifie pas que toutes les autres sont identiques
  • Exemple cité : l’attitude consistant à conclure d’emblée que les personnes âgées ne comprennent pas l’informatique
  • Réduire l’ensemble des femmes à une image issue de relations familiales personnelles relève de la même erreur

• Supposer que les personnes et les organisations sont fixes

  • À l’échelle macro, la personnalité évolue avec le temps
  • À l’échelle micro, la persona au travail diffère de la personne à la maison, et les jugements changent aussi selon le stress ou certaines conditions

• Supposer que ce qui est dit correspond à ce qui est pensé

  • Certaines personnes veulent dire exactement ce qu’elles disent, d’autres non
  • Beaucoup pensent parler avec sincérité alors que, dans les faits, ce n’est pas toujours le cas

• Juger les gens

  • Détester ou balayer quelqu’un qui a mal compris quelque chose de mal documenté réduit fortement la possibilité de réellement l’écouter
  • Partir du principe que l’autre travaille mal ou mène mal sa vie est aussi un facteur qui entrave l’écoute

• Traiter 80 personnes comme un seul groupe plutôt que comme 80 individus

  • Le B2B est, à certains égards, encore plus humain que le B2C : les relations, les dynamiques et des éléments comme le soft power en dehors de l’organigramme y jouent un rôle
  • Avec la dynamique de groupe, des variables encore plus complexes apparaissent qu’au niveau individuel

Le décalage entre exigences figées et logiciel

• Parce que les personnes et les organisations changent, la fixed project management n’est pas adaptée à la fabrication logicielle
• Même si les exigences sont fixées au départ, les personnes changent entre-temps, et lorsque le résultat arrive, il ne correspond au mieux qu’à la demande formulée au lancement
• Au moment du déploiement, ce n’est peut-être déjà plus ce qui est souhaité, et comme chacun ajoute ses propres attentes pendant l’attente, la réalité ne correspond finalement à aucune de ces attentes

Résultats et effets

• Quand on n’écoute pas correctement ce que disent les gens, on passe à côté des insights les plus précieux, ce qui mène à la perte d’opportunités de revenus et d’avantages concurrentiels
• Plus les malentendus s’accumulent, plus de nouveaux éléments s’ajoutent ensuite au code sur lequel il faudra continuer à travailler ; l’écoute est aussi liée à la réduction de certaines causes de tech debt
• Plus on repère les moments où l’on n’écoute pas, plus on a de chances de mieux écouter

[GN⁺]

Avis sur Hacker News

• J’ai tendance à choisir mes mots avec précision, et si j’emploie une certaine formulation, c’est vraiment ce que je veux dire. Pourtant, beaucoup de gens parlent, à mes yeux, comme un poème tonal, en tournant autour avec des mots approximatifs et en s’attendant à être compris via une nuance commune, ce qui rend l’interprétation fatigante. Quand j’écris, chaque mot est choisi délibérément, mais même au travail, on interprète presque toujours mes propos comme s’ils étaient imprécis, et c’est assez pénible. Je suis peut-être sur le spectre, mais je n’ai jamais été diagnostiqué. Il y a environ six mois, j’ai créé un petit RPC et rédigé sa documentation pour permettre à une autre équipe de lancer un long travail. Le document faisait moins d’une page, mais il était complet, exact et concis. Pourtant, mon manager l’a fait passer dans une IA avant de le transmettre, sans même expliquer pourquoi, et je n’étais même pas au courant. En moins d’une journée, j’ai reçu une avalanche de retours absurdes, et en regardant les exemples de requêtes réelles, j’ai vu qu’il y avait eu une altération d’endpoint. Ce n’était pas une simple faute de frappe : l’adresse avait été entièrement inventée, et dans le document, l’endpoint comme les paramètres obligatoires étaient tous faux, avec même des fonctionnalités inexistantes ajoutées de toutes pièces. D’habitude je suis plutôt patient, mais je n’ai jamais été aussi en colère, et ça me met encore en rage aujourd’hui. Si le marché de l’emploi n’était pas ce qu’il est, j’aurais probablement démissionné sur-le-champ. Confier à l’IA un langage que les gens devraient lire et interpréter eux-mêmes, ça me donne l’impression d’une mort du langage rigoureux, et ça fait des mois que je me demande sérieusement si l’IA générative n’est pas une sorte de Great Filter qui va détruire la civilisation

  • Cette vision me paraît un peu étrangère. Je ne pense pas que la parole découpe proprement les frontières de la pensée ; le langage est un outil pour exprimer le monde et la compréhension de chacun, donc expliquer des idées proches avec des mots différents est naturel. Pour la personne qui transforme sa pensée en mots, cela peut sembler plus clair, mais pas forcément pour celle qui écoute. Donc je ne pense pas qu’on puisse évacuer à la légère le travail d’interprétation. Si vous discutiez avec l’autre camp dans cette situation, je pense qu’eux aussi diraient sans doute qu’ils ont du mal à interpréter vos paroles
  • Le cadre est si fort que j’ai tout de suite pensé à un roman. L’idée qui relie le Great Filter et l’IA générative est excellente, et ça ressemble à une histoire que Cory Doctorow devrait écrire immédiatement
  • Je pense qu’il faut d’abord demander pourquoi le manager a mis ce document dans une IA. Parfois, plus la précision augmente, plus la lisibilité diminue, et plus le langage est compressé, plus le lecteur doit dépenser d’effort cognitif sur chaque mot. Lire, c’est traduire le modèle mental de l’auteur en modèle mental du lecteur ; ce n’est pas une conversion automatique mot à mot, cela exige un acte d’interprétation. Si c’est trop concis, les aides destinées au lecteur peuvent disparaître. Il est possible qu’un détour comme un résumé par IA ait eu lieu justement parce qu’un document d’une page était trop court pour aider un lecteur ordinaire à comprendre. Écrire pour le lecteur est un travail totalement différent de la prise de notes précise destinée au lecteur le plus contextualisé, et surtout quand on s’adresse à un public indéterminé, il faut souvent aider la compréhension avec des répétitions, des exemples simples, un contexte familier, des étapes plus détaillées, parfois même de l’humour et des explications de fond
  • J’ai vécu quelque chose de similaire récemment. J’avais écrit une spécification de quatre pages, et la personne en face ne l’a pas lue : elle a juste demandé à un LLM d’en tirer quelques bullet summaries, et j’ai reçu en retour une proposition qui ne correspondait pas aux exigences. Quand j’ai objecté, il m’a répondu que cela aurait dû figurer dans la spécification d’origine, alors que c’y était déjà ; ça n’apparaissait simplement pas dans son LLM summary. Je ne suis pas du genre à m’accrocher à chaque mot, mais j’ai du mal à croire que l’information contenue dans quatre pages puisse tenir intégralement dans dix puces
  • J’ai plutôt l’impression qu’un prompt dédié ou un LLM personnalisé pour transformer ce texte en normie speak serait précisément le bon cas d’usage

• Rien qu’en lisant ce fil de commentaires, je trouve ironique de voir autant de gens reproduire exactement le problème que le texte dénonçait. J’aimerais ajouter quelques points. D’abord, on peut accumuler autant de savoir et de débat qu’on veut, si l’autre ne veut pas accepter quelque chose, il ne l’acceptera pas facilement. Ensuite, écouter vraiment consiste à se rendre vulnérable, mentalement comme physiquement. On entend alors des choses qui entrent en conflit avec son expérience, ses croyances et sa vision du monde, et l’attitude qui consiste à juger les gens sert souvent de mécanisme d’autoprotection, ce qui empêche justement de bien écouter. Enfin, écouter, c’est souvent ne pas sauter immédiatement vers une solution, mais absorber la souffrance de l’autre et la traiter. Par exemple, un Product manager peut être tenté de tout réduire tout de suite à une nouvelle fonctionnalité ou à un ticket, alors qu’il faudrait d’abord écouter les cas d’usage, identifier les points de douleur et les résoudre, au lieu de simplement essayer de comprendre le nom de la fonctionnalité demandée par l’utilisateur

  • Je trouve dangereux de présupposer cela d’avance. La plupart des choses laissent place à la négociation, et elles peuvent changer si l’on sait négocier correctement
  • Le point 2, en particulier, m’a paru très profond. J’ai envie d’envoyer ça à quelqu’un qui m’est cher, en espérant qu’il ou elle listen vraiment
  • Je comprends l’idée que l’écoute est une forme de vulnérabilité, mais j’aimerais aussi qu’il soit garanti que cette vulnérabilité ne soit pas exploitée à chaque fois ; dans ce cas, je prendrais volontiers le temps d’écouter correctement, systématiquement
  • Je me pose une vraie question : qu’est-ce que cela signifie concrètement absorber la souffrance de quelqu’un, et comment passe-t-on ensuite naturellement à la définition d’une fonctionnalité ou à la rédaction d’un ticket ?
  • Cette description me paraît être précisément l’essence du presales discovery. C’est un domaine qui relève presque plus de l’art que de la technique

• Je suis d’accord avec le constat de fond, mais cette liste m’a quand même semblé relever un peu de la plainte. Une communication efficace est presque un problème central pour l’humanité tout entière, et ce texte donne un peu l’impression de réprimander les développeurs parce qu’ils ne savent pas écouter, ce qui m’a semblé légèrement condescendant. Le problème fondamental, c’est que les gens ne savent pas ce qu’ils ignorent. Les meilleurs communicants sont comme des traducteurs, et les gens n’écoutent vraiment que lorsque le message devient évident dans leur propre cadre de compréhension. Je ne crois pas qu’il s’agisse simplement d’un effondrement où tout le monde se comporte comme un enfant qui se bouche les oreilles. C’est pour cela qu’on cherche des systèmes et de l’ingénierie : pour que les systèmes embarquent des mécanismes de détection des écarts et des cadres de traduction. Ce n’est pas parfait, mais je pense qu’il est plus important de changer l’environnement au niveau des équipes, des entreprises et des systèmes que de sermonner les individus en leur disant simplement de mieux écouter

  • Cela me rappelle ce qu’un vieil homme m’avait dit autrefois : il faut voir cela comme un Noisy system. Le signal est toujours plus faible que le bruit, et il est transporté par des humains limités. Chacun a une limite à ce qu’il peut faire, il y a une limite à la vitesse à laquelle le modèle mental d’une personne peut se mettre à jour, et les limites d’un groupe sont encore plus basses que celles d’un individu. Les grandes organisations, en particulier, peuvent mettre des décennies à changer leurs modèles, même quand la réalité a complètement basculé. Du coup, il est important de reconnaître ces contraintes puis de décider où investir son temps et son énergie
  • Ce texte m’a simplement paru être un texte de self-help assez ordinaire, et même un peu en dessous à cause du manque d’exemples
  • Je suis développeur mais j’ai aussi fait pas mal d’autres choses, donc je connais bien l’importance de la communication et à quel point les développeurs y sont souvent faibles. Le schéma classique, c’est qu’ils se comportent comme de mauvais médecins : ils font semblant d’écouter mais posent un diagnostic beaucoup trop tôt. Ils décrètent savoir ce qu’il faut avant même que l’autre ait fini d’expliquer l’essentiel. En logiciel, ce que le client a réellement besoin importe souvent davantage que ce qu’il dit vouloir. Les clients qui savent vraiment formuler une manière élégante de résoudre leur problème avec du logiciel sont rares ; en général, quelqu’un arrive avec une idée sans avoir profondément réfléchi au logiciel. Cela ne veut pas dire que l’idée n’a aucune valeur, mais seulement que le travail de clarification des besoins et de formulation de la solution n’est pas terminé. On complète cela par l’observation, l’explication et la conversation. D’après mon expérience, beaucoup de développeurs écoutent vraiment mal, et les médecins ou d’autres professions techniques font souvent la même chose. Ils veulent vite paraître compétents en montrant tout ce qu’ils savent, et classent l’autre dans une catégorie de problèmes qu’ils pensent déjà connaître. Parfois ça marche, mais tôt ou tard ça échoue
  • Pour plaisanter, si la communication est vraiment le problème central de l’humanité, alors il devrait bien y avoir quelque part un verset à ce sujet dans la Bible

• Je pense qu’il ne faut pas supposer trop vite que ce que les gens disent correspond exactement à ce qu’ils pensent réellement. À l’inverse, celui qui parle croit facilement que celui qui écoute imagine la même chose et comprend de la même manière. C’est pourquoi il est important d’écrire de façon aussi détaillée et non ambiguë que possible. Si, en réunion, quelqu’un essaie d’expliquer un objectif avec une seule puce de six mots, j’y vois surtout le signe que personne ne comprend réellement l’objectif. Et si quelqu’un arrive en réunion sans même une page de document, c’est qu’il n’a probablement pas encore assez compris le sujet ; si l’avancement de mon travail dépend de ce résultat, je pense qu’il faut exiger une image plus claire

  • Il m’arrive souvent de devoir répéter about what? plusieurs fois par jour à mes collègues. Il faut parfois demander quatre ou cinq fois de suite jusqu’à ce qu’ils précisent de quel client, de quelle fonctionnalité ou de quel produit ils parlent. Et parfois je dois le faire même quand je sais déjà exactement ce qu’ils veulent dire
  • J’ai aussi le sentiment qu’il faut toujours examiner la légitimité des exigences. Le moyen le plus simple de masquer le fait qu’on ignore le besoin réel, c’est souvent l’excès de demandes. D’après mon expérience, demander dix fois plus que nécessaire est courant, et j’ai déjà entendu quelqu’un défendre une option 500 fois plus chère en disant qu’il fallait acheter le plus haut de gamme pour ne pas avoir à s’inquiéter de l’avenir
  • Écrire de façon détaillée et non ambiguë est peut-être une condition préalable à une compréhension mutuelle profonde, mais ces dernières années, j’ai l’impression que les gens lisent de moins en moins au-delà de la première phrase d’un message, d’un ticket ou d’un e-mail. Du coup, on doit souvent découper l’information en très petits morceaux et la faire avaler ainsi, ce que je déteste assez profondément
  • J’ai l’impression que ce genre de chose arrive bien trop souvent dans la réalité. Quand je dis pas prêt pour la production, la direction l’entend souvent comme : on peut vendre ça au client comme de l’acceptance testing
  • Cela m’a soudain rappelé le film soviétique Kin-dza-dza. À un moment, un personnage décrit quelqu’un en disant qu’il dit ce qu’il ne pense pas et pense ce qu’il ne pense pas, et je trouve que cela correspond assez bien à la confusion de cette conversation

• J’occupe surtout des rôles liés à la gestion de la relation client, donc je pense que la chose la plus importante est d’aligner les attentes du client avec la réalité. Si l’on aligne les attentes du client avec ce qui est possible, le temps que cela prendra, ce que cela coûtera et le moment où cela pourra être mis en production, alors même si la date de démarrage ou le coût ne lui plaît pas, on obtient au final un client satisfait. Le coût, surtout, fait souvent échouer un deal, donc j’essaie généralement de fixer un ordre de grandeur assez tôt. On peut écouter et faire preuve d’empathie autant qu’on veut, la réalité reste la réalité, et le client doit aussi reconnaître ou accepter ces contraintes. Le chargé de compte qui approuve tout ce que veut le client finit par le rendre plus malheureux, et une bonne interface entre le client et l’interne consiste à écouter les deux côtés pour faire coïncider ce qui peut réellement être livré avec les attentes du client

• J’ai parfois l’impression qu’on passe peut-être trop de temps à communiquer. Quand on alloue trop de temps, l’attention se dissipe et il devient facile de remettre à plus tard en se disant qu’on clarifiera de toute façon au prochain tour. Je pense qu’en réduisant les réunions inutiles et en n’allouant qu’un minimum viable time, tout le monde écouterait au contraire mieux

  • Je n’ai presque jamais vu ce phénomène dans la réalité. La plupart des réunions ne sont en fait pas de la communication mais plutôt des consignes et des annonces, et la capacité d’écoute est une compétence distincte qui n’a pas grand-chose à voir avec la durée d’une réunion. L’écoute attentive est une capacité qui se travaille par la pratique ; elle n’apparaît pas automatiquement parce qu’on raccourcit les réunions
  • J’ai participé à bien trop de réunions dont le seul résultat était de programmer la suivante. J’ai même vu le schéma où l’on fait venir encore plus de monde, où l’équipe la plus nombreuse oriente les décisions de son côté pour gagner en influence politique, et où cela finit par produire encore plus d’embauches et de réunions inutiles. La sortie, ce n’est pas d’augmenter la communication, mais de définir une vision unique et de réduire les dépendances entre équipes pour que chacune puisse travailler de manière autonome
  • En travaillant sur l’architecture logicielle, j’ai souvent vu qu’un simple diagramme permettait d’économiser plus de 60 minutes de discussion et plusieurs réunions. Même s’il n’était pas très bien dessiné, un schéma fidèle aux faits suffisait, et pour une logique complexe ou non triviale, un diagram était bien plus clair que des mots. En réunion à distance, on peut le dessiner rapidement avec un Ai agent et Mermaid.js ; en présentiel, un tableau blanc ou du papier et un stylo suffisent
  • J’ai l’impression que passer du temps à communiquer et communiquer réellement sont deux choses totalement différentes
  • Je pense qu’en réalité, le problème n’est pas qu’on passe trop de temps à communiquer, mais qu’on passe trop de temps à faire semblant de communiquer. On force des réunions sans quorum, on les lance sans prérequis, on balance un AI slop document pondu sans réflexion, puis quand les gens ne comprennent pas, on les fait presque passer pour stupides. Les trente premières minutes ressemblent à du gaslighting, puis dans les dix dernières on reconnaît enfin que tout cela était une perte de temps et on essaie de sauver les meubles. Une réunion devrait au départ servir à partager une pensée bien mûrie et une direction cohérente, puis à recueillir des retours pertinents sur une proposition claire ; en pratique, on passe souvent son temps à gérer la tentative de quelqu’un de transformer son propre travail en projet de groupe façon stone soup. Si on demande dès le début quel est l’objectif de la réunion, on découvre souvent que l’organisateur a simplement ouvert un groupe d’étude improvisé. Les managers qui n’ont qu’une vision très macro s’imaginent que le travail se fait en réunion, sans voir le travail de réflexion nécessaire en amont d’une bonne réunion. Si l’on se précipite pour communiquer avant que la pensée soit structurée, la réunion ne produit que du bruit. Dans ce genre de situation, l’attitude la plus puissante est regardons cela ensemble maintenant, et je fais respecter l’ordre de dépendance Why, What, How, Who, When. Si l’amont est vide, on ne passe pas à la suite ; que ce soit un stagiaire ou un VP, je n’accepte pas les échappatoires faciles. Si après avoir décomposé le problème et réfléchi sur le terrain, l’équipe ne change toujours pas, alors il vaut probablement mieux chercher une autre équipe

• Je trouve que l’observation sur le specialism effect dans ce texte est assez sous-estimée. Moi aussi, il m’est arrivé de m’agacer parce qu’un utilisateur ne comprenait pas quelque chose que j’avais mis des années à intégrer, avant de réaliser que le problème n’était pas l’absence de savoir, mais le fait qu’il était accumulé ailleurs. Eux aussi avaient simplement passé le même temps à approfondir tout autre chose

• Je ne suis pas complètement d’accord avec l’idée que la cause centrale serait que les gens ne parlent pas et n’écoutent pas. Pour reprendre une métaphore de bande dessinée, j’ai l’impression que beaucoup de gens voulaient surtout couper le ruban plutôt que construire la route, et comme ils ont obtenu cela, on en est arrivé là

• J’ai souvent trouvé assez drôle le fait que des gens affirment vouloir dire exactement ce qu’ils disent, alors qu’en pratique ce n’est pas le cas. Il m’est arrivé de reformuler presque mot pour mot ce que quelqu’un venait de dire pour vérifier ma compréhension, et de recevoir en retour un démenti énergique : ce n’était absolument pas ce qu’il voulait dire

• J’ai l’impression qu’au cœur de beaucoup de problèmes lorsqu’on parle avec des profils non techniques, il y a le fait qu’ils demandent simplement d’ajouter X ou de changer Y sans aucun contexte de coût. Bien sûr, on peut faire presque tout ce qu’on demande, mais chaque demande a un coût, et si on ne comprend pas cela, c’est difficilement compatible avec la livraison fiable d’un produit

  • J’ai plutôt l’impression que cette réponse illustre exactement le propos du texte. Ce n’est pas qu’ils ne comprennent pas le coût ; c’est simplement un contexte différent, et le rôle des profils techniques n’est pas d’attendre qu’ils arrivent déjà en connaissant les coûts, mais de les aider à faire des tradeoffs informés
  • Je pense que dans ce genre de situation, poser les whys est important. Si l’on comprend le processus non technique, on se rend parfois compte qu’il n’est même pas nécessaire d’ajouter ou de modifier quoi que ce soit. Je suis aussi d’accord sur le fait que si l’on empile tout, on finit par créer un monstre façon Turing complete Excel/Email clone
  • Je pense qu’il existe dans ces cas une asymétrie où les non-techniciens ne connaissent pas les coûts, tandis que les techniciens ne connaissent pas les bénéfices. Au final, il faut de la communication des deux côtés pour trouver un point d’équilibre raisonnable entre coût et bénéfice
  • J’ai l’impression que c’est un problème assez résoluble. Il suffit d’estimer, pour chaque demande, combien de mois cela prendra et combien de dollars cela coûtera, puis de répondre en ces termes
  • Je pense malgré tout qu’aujourd’hui, l’IA prend en charge une partie du code thing, et que le coût d’implémentation a effectivement pas mal baissé. Qu’on aime ou non cette évolution, il faut reconnaître qu’elle existe