Les impacts de la technologie sur nos sociétés (IA, Robotique, géo-ingénieurie, etc...)

Axoulotl08 · 03/06/2025, 11h48

Citation :

Publié par Ron Jeu Vidéo

La question c'est combien de temps reste-t-il avant que la qualité ne soit plus une différence notable ?

Quelques décennies et/ou l'émergence d'une vraie IA.

Ron Jeu Vidéo · 03/06/2025, 11h51

[ ... ]

Axoulotl08 · 03/06/2025, 11h53

[ ... ]

**TabouJr** · 03/06/2025, 11h56

Allez sur le labo pour expliquer comment fonctionnent les balises script, ici ce n'est pas le bon forum.

Ron Jeu Vidéo · 03/06/2025, 11h57

[ ... ]

**TabouJr** · 03/06/2025, 12h00

Temps mort.

Réouverture. Tenez vous en aux aspects politique, économique et social du sujet.

**Doudou Spuiii** · 03/06/2025, 14h08

Citation :

Publié par Axoulotl08

Quelques décennies et/ou l'émergence d'une vraie IA.

Je suis toujours étonné de voir à quel point les gens ne voient pas la révolution en court, y a 2 ans, les gens rigolaient de la vidéo de Will Smith qui mange des spaghetti, maintenant avec Veo3, les gens en viennent à se demander quand ils voient une vidéo est vraie ou pas.
C'est pareil pour le code, "quelques décennies" mais lol, rien que l'année prochaine, on aura surement d'énormes avancées.

Le problème de l'IA pour le code, c'est surtout qu'elle ne peut pas faire tout un projet avec juste un prompte, faut faire pas à pas toutes les classes, comme tu dois écrire un livre chapitre par chapitre et chaque chapitre tu les fais page par page. Et au bout d'un moment, il a oublié ce qu'il a écrit 10 chapitres avant, donc faut faire gaffe, pour le code c'est pareil.
Et y a aussi toute la partie maintenance et sécurité qu'il ne gère pas, il peut rendre des trucs utilisables en one shot, moi je l'utilise pour des minis outils perso à la con en python pour automatiser le travail sur des fichiers par exemple, la où avant, tu pouvais passer des heures à faire des macrons en VB sur excel pour un truc qui marche pas ou plus après un changement de version. Et je fais ça alors que je sais pas coder en python mdr.

Vu l'évolution folle de 2023 à maintenant, ce qu'on aura en 2027 devrait être fou, je pense pas qu'on aura besoin d'attendre 20-30 ans, vu la vitesse à laquelle tout va, c'est impossible de savoir tout ce qu'on pourra faire en 2050.
Pour moi, les devs qui ne sont pas inquiets, c'était les traducteurs ou les graphistes dans le déni d'il y a 3 ans, ça va être tendu, ça se voit déjà dans l'emploi des informaticiens à l'heure actuelle d'ailleurs.

SekYo · 03/06/2025, 14h13

Citation :

Publié par Noumenon

C'est deja le cas chez cloudflare. Cf le projet link plus haut qui a été entierement codé par Claude, avec des humains qui font uniquement de la review.

edit: pour ceux que ca interesse, l'historique des commit est surement la partie la plus interessante, et il contient tous les prompts utilisés.
le premier commit: https://github.com/cloudflare/worker...9fe49439a0779c

Du coup j'ai été voir la tronche des prompts sur quelques dizaines de commits et... comment dire. Bin la personne qui est capable d'écrire ces prompts, pour moi c'est clairement un développeur en fait hein. Un exemple dans les 10 premiers commits de l'historique:

Citation :

Prompt: I think it's not necessary to store clients_list. Workers KV has a list() function you can use instead, which would be better because it is not susceptible to consistency problems if multiple updates happen concurrently. Can you change this?

Pour demander ces modifications, faut être capable de comprendre le code initialement généré, comprendre que le OAUTH_KV a une méthode "list" qui peut être utile et qui fixe le bug potentiel, etc... Bref, faut être développeur (ou en tous cas avoir des connaissances très proches). Et des exemples comme celui là, y en a pleins.

Et en dehors des prompts qui demandent d'écrire de la doc, la plupart des prompts "codes" sont comme ceux là: très précis. Et honnêtement pour certains de ces prompts, je pense que ça prend plus de temps à écrire le prompt précis qu'à faire le refacto directement, surtout si tu es avec un IDE et/ou un langage qui a déjà du bon tooling pour ça (genre Intellij et Java, j’avoue que ça fait longtemps que j'ai pas utilisé Webstorm avec Typescript donc pour ce cas précis je ne sais pas).

Bref pour moi ça reste un outil, et comme tout outil, c'est utile dans certains cas et inutiles dans d'autres. Le truc chiant c'est quand dans le upper management t'as que des profils à la Ron, qui connaissent que le marteau, pour qui tout les problèmes sont des clous et qui veulent utiliser un marteau pour tout. Les coding assistant à base de LLM ça a du sens dans certains cas, ça booste la productivité parfois, mais ça dépend de pleins de variables...

**Dr. Troy** · 03/06/2025, 14h22

Citation :

Publié par Doudou Spuiii

Je suis toujours étonné de voir à quel point les gens ne voient pas la révolution en court, y a 2 ans, les gens rigolaient de la vidéo de Will Smith qui mange des spaghetti, maintenant avec Veo3, les gens en viennent à se demander quand ils voient une vidéo est vraie ou pas.
C'est pareil pour le code, "quelques décennies" mais lol, rien que l'année prochaine, on aura surement d'énormes avancées.

Le problème de l'IA pour le code, c'est surtout qu'elle ne peut pas faire tout un projet avec juste un prompte, faut faire pas à pas toutes les classes, comme tu dois écrire un livre chapitre par chapitre et chaque chapitre tu les fais page par page. Et au bout d'un moment, il a oublié ce qu'il a écrit 10 chapitres avant, donc faut faire gaffe, pour le code c'est pareil.
Et y a aussi toute la partie maintenance et sécurité qu'il ne gère pas, il peut rendre des trucs utilisables en one shot, moi je l'utilise pour des minis outils perso à la con en python pour automatiser le travail sur des fichiers par exemple, la où avant, tu pouvais passer des heures à faire des macrons en VB sur excel pour un truc qui marche pas ou plus après un changement de version. Et je fais ça alors que je sais pas coder en python mdr.

Vu l'évolution folle de 2023 à maintenant, ce qu'on aura en 2027 devrait être fou, je pense pas qu'on aura besoin d'attendre 20-30 ans, vu la vitesse à laquelle tout va, c'est impossible de savoir tout ce qu'on pourra faire en 2050.
Pour moi, les devs qui ne sont pas inquiets, c'était les traducteurs ou les graphistes dans le déni d'il y a 3 ans, ça va être tendu, ça se voit déjà dans l'emploi des informaticiens à l'heure actuelle d'ailleurs.

Comme je le disais plus haut la progression n'est même plus linéaire.
Ce n'est "que" de l'évolution de ce qui existe déjà, certes impressionnante mais sans changement de paradigme, on fera juste mieux (au dépend d'une consommation de plus en plus énorme, et donc d'un truc toujours moins rentable) mais on ne dépassera pas les plafonds actuels.

Bref, personne ne peut prédire quand (6 mois ? 10 ans ?) et même si ça se fera.

Et idem pour les graphistes, malgré l'évolution de la génération d'image, c'est la même perte de temps qu'en code, si tu es graphiste, tu perds moins de temps à faire les modifications toi même (et la encore, les outils aident, ceux d'Adobe ont du sens contrairement aux générateurs d'image) et tu n'as jamais un truc qui répondrait à un brief précis (ou alors en perdant plus de temps et d'énergie qu'à le faire soit même). Ça fait gagner du temps, permet d'en faire plus, mais ça ne remplace pas du tout le métier.

Axoulotl08 · 03/06/2025, 14h24

Citation :

Publié par Doudou Spuiii

C'est pareil pour le code, "quelques décennies" mais lol, rien que l'année prochaine, on aura surement d'énormes avancées.

Bah va regarder les promptes de l'exemple de Cloudfare. Comme dit au dessus, un dev réel aurait limite été plus rapide.
Quand le prompteurs fait 95% du taff du modèle LLM avant, désolée mais ça ne m'impressionne pas du tout. Je comprends que pour des néophytes c'est jolie, c'est beau, mais derrière bah c'est autant de boulot pour un dev.
Si je doit faire un prompt aux poils de cul pour que le modèle ponde un truc correcte, j'ai aussi vite fait de le faire avec un IDE récent... Les modèles évoluent vite oui, ils s'améliorent mais derrière comme déjà dit c'est a chier et faut tout relire/reprendre. C'est aussi long que de le faire à la main...

Noumenon · 03/06/2025, 14h25

Citation :

Publié par SekYo

Du coup j'ai été voir la tronche des prompts sur quelques dizaines de commits et... comment dire. Bin la personne qui est capable d'écrire ces prompts, pour moi c'est clairement un développeur en fait hein. Un exemple dans les 10 premiers commits de l'historique:

Pour demander ces modifications, faut être capable de comprendre le code initialement généré, comprendre que le OAUTH_KV a une méthode "list" qui peut être utile et qui fixe le bug potentiel, etc... Bref, faut être développeur (ou en tous cas avoir des connaissances très proches). Et des exemples comme celui là, y en a pleins.

Et en dehors des prompts qui demandent d'écrire de la doc, la plupart des prompts "codes" sont comme ceux là: très précis. Et honnêtement pour certains de ces prompts, je pense que ça prend plus de temps à écrire le prompt précis qu'à faire le refacto directement, surtout si tu es avec un IDE et/ou un langage qui a déjà du bon tooling pour ça (genre Intellij et Java, j’avoue que ça fait longtemps que j'ai pas utilisé Webstorm avec Typescript donc pour ce cas précis je ne sais pas).

Bref pour moi ça reste un outil, et comme tout outil, c'est utile dans certains cas et inutiles dans d'autres. Le truc chiant c'est quand dans le upper management t'as que des profils à la Ron, qui connaissent que le marteau, pour qui tout les problèmes sont des clous et qui veulent utiliser un marteau pour tout. Les coding assistant à base de LLM ça a du sens dans certains cas, ça booste la productivité parfois, mais ça dépend de pleins de variables...

Tout a fait. Pour moi le futur de ca, c'est un IDE qui integre tout ca, et un dev qui peut en faire le travail de 10. Alors ptetre que y aura plus de travail aussi, ce qui permettra d'eviter un chomage de masse. Mais ce chomage de masse represente un risque collossal pour nos sociétés.

La bonne nouvelle, c'est que les mecaniques qui permettent de se premunir de ce risque sont aussi celles que nous devrions faire pour réduire les inégalités.

Citation :

Bah va regarder les promptes de l'exemple de Cloudfare. Comme dit au dessus, un dev réel aurait limite été plus rapide.

Je met ici un lien vers la discussion de ce sujet sur hacker news: https://news.ycombinator.com/item?id=44159166

Le developpeur en question a contribué au sujet:

Citation :

It took me a few days to build the library with AI.
I estimate it would have taken a few weeks, maybe months to write by hand.
That said, this is a pretty ideal use case: implementing a well-known standard on a well-known platform with a clear API spec.
In my attempts to make changes to the Workers Runtime itself using AI, I've generally not felt like it saved much time. Though, people who don't know the codebase as well as I do have reported it helped them a lot.
I have found AI incredibly useful when I jump into other people's complex codebases, that I'm not familiar with. I now feel like I'm comfortable doing that, since AI can help me find my way around very quickly, whereas previously I generally shied away from jumping in and would instead try to get someone on the team to make whatever change I needed.

Axoulotl08 · 03/06/2025, 14h29

Citation :

Publié par Noumenon

Tout a fait. Pour moi le futur de ca, c'est un IDE qui integre tout ca, et un dev qui peut en faire le travail de 10.

Tu penses vraiment qu'un mec qui va devoir relire TOUT ce qu'a fait le modèle en plus de devoir faire les promptes au poil de cul limite au niveau d'un dev va être capable de remplacer 10 dev ?Tu m'excuseras d'en doute très fortement.

SekYo · 03/06/2025, 14h37

Citation :

Publié par Noumenon

Tout a fait. Pour moi le futur de ca, c'est un IDE qui integre tout ca, et un dev qui peut en faire le travail de 10. Alors ptetre que y aura plus de travail aussi, ce qui permettra d'eviter un chomage de masse. Mais ce chomage de masse represente un risque collossal pour nos sociétés.

Y aura des gains de productivité, mais je doute fortement que ce soit un facteur 10, surtout dans le monde occidental. Je veux dire, je ne pense pas qu'il y ait encore beaucoup de dev en Europe/US qui font que "pisser du code" en se basant sur des specs ultra précises.
La partie purement "écriture de code" (ie traduire en C/Java/Python un besoin) c'est quoi ? Entre 10% et 50% (en étant gentil) grand max du temps de la majorité des devs ? Bien sur ça va dépendre de la boite, du type de projet, du secteur, du niveau de séniorité etc... Un dev aujourd'hui, il fait plein d'autre chose que juste écrire du code. Déjà il passe probablement beaucoup plus de temps à LIRE le code existant et tu ajoutes à ça le temps liés aux code reviews, aux bugfix (dans un projet conséquent copier/coller le message d'erreur dans le prompt suffit rarement), à comprendre les specs ou à participer à les écrire, aux différents rituels d'équipe/de la boite etc...

Cpasmoi · 03/06/2025, 14h41

On a un hackweek cette semaine et on a décidé d'utiliser Claude pour effectuer la conversion d'un langage vers un autre.

Je vous reviens, ça va être drôle.

Airmed / Ildefonse · 03/06/2025, 14h42

Citation :

Publié par Noumenon

Tout a fait. Pour moi le futur de ca, c'est un IDE qui integre tout ca, et un dev qui peut en faire le travail de 10. Alors ptetre que y aura plus de travail aussi, ce qui permettra d'eviter un chomage de masse. Mais ce chomage de masse represente un risque collossal pour nos sociétés.

Copilot est préintégré (et peut pas etre enlevé) de VSCode. Si tu cherches, il y a énormément de reponse sur google de personnes qui veulent le virer

Cpasmoi · 03/06/2025, 14h43

Oui j'ai également viré toutes les autocomplétion des IDE Jetbrains, c'était un putain de calvaire, et tu ne savais jamais qui avait généré le code proposé.
Le inline completion, c'est un peu comme avoir un enfant de 5 ans qui te hurle "et pourquoi tu fais ça ? et pourquoi tu fais pas ça ?" en boucle dans les oreilles pendant que tu essaies de réfléchir.

Noumenon · 03/06/2025, 14h44

L'auto-completion est une mauvaise integration IMO. Je vois plutot ca comme un dialogue avec le modele, qui finit par proposer des changements que tu peux accepter / refuser.

Cpasmoi · 03/06/2025, 14h45

C'est co-pilot chat ça.

**Caniveau Royal** · 03/06/2025, 14h47

Citation :

Publié par SekYo

Un dev aujourd'hui, il fait plein d'autre chose que juste écrire du code. Déjà il passe probablement beaucoup plus de temps à LIRE le code existant et tu ajoutes à ça le temps liés aux code reviews [...]

Ces temps-ci, on se demande si c'est pas participer peu ou prou à du devops qui bouffe tout notre temps.
Le truc à coller en Docker ou en Pod... Les devs en dev containers, etc.
C'est devenu presque plus long de réussir à déployer certaines applications que de réussir à les coder.
[Et j'allais oublier Agile]. Putain, je me raye, j'aillais déjà m'énerver.

Airmed / Ildefonse · 03/06/2025, 14h50

Citation :

Publié par Cpasmoi

Oui j'ai également viré toutes les autocomplétion des IDE Jetbrains, c'était un putain de calvaire, et tu ne savais jamais qui avait généré le code proposé.
Le inline completion, c'est un peu comme avoir un enfant de 5 ans qui te hurle "et pourquoi tu fais ça ? et pourquoi tu fais pas ça ?" en boucle dans les oreilles pendant que tu essaies de réfléchir.

La réponse de VSCode c'est de cliquer sur "chat" pour le virer, sauf que l'option est grisée ... Perso ca me gonfle, cela me bouffe de la place visuel et j'ai rien trouvé pour le virer.
C'est d'ailleurs une des raisons pour laquelle j'ai viré W11, cela sent vraiment le "tu veux pas d'AI ? Balek, tu l'auras et tu pourras pas le virer" en espérant que par contrainte les utilisateurs l'utilisent. Cela se retrouve même dans les configs PC avec des trucs à la "IA ready".
Si c'était vraiment si bien que cela, il n'y aurait pas besoin de cette stratégie commerciale.

Cpasmoi · 03/06/2025, 14h52

Malheureusement, il y a bien longtemps que l'industrie du logiciel a cessé d'accepter "non" comme réponse.
Cela fait au moins 10 ans que je dis non à facebook quand il me demande mon numéro de téléphone, et bien, il me l'a quand même volé.

Ron Jeu Vidéo · 03/06/2025, 14h52

Sommaire :

1. Centraliser la source de vérité
2. Utiliser un store adapté
3. Automatiser avec un CRUD simple
En pratique :
1. Contextes courants à préciser

Solution “pro” (cas général)

a) Évite de maintenir une liste “statique”
b) Utilise le moteur de stockage pour indexer
c) Automatisation
Cas Workers KV (Cloudflare)
Exemple pseudo-code

À retenir

Citation :

Publié par SekYo

Du coup j'ai été voir la tronche des prompts sur quelques dizaines de commits et... comment dire. Bin la personne qui est capable d'écrire ces prompts, pour moi c'est clairement un développeur en fait hein. Un exemple dans les 10 premiers commits de l'historique:

C'est intéressant, parce que moi j'aurai été incapable de faire un tel prompt effectivement.

La question c'est combien de temps la différence de qualité va se faire ressentir dans la réponse générée entre ce prompt technique et ma façon de parler à l'IA :

Citation :

je suis un projet là, ça me soûle de devoir enregistrer une liste des clients à chaque fois, comment automatiser tout ça ? que me conseilles tu ?

Imo, le terrain entre les deux va drastiquement se réduire et très vite. Par exemple, si je prends la peine de passer en mode projet, et que je documente bien et que j'ai des instructions personnalisées qui viennent palier à cette différence technique, on doit pouvoir bien réduire l'écart.

De ce que j'observe de l'IA, avec mon prompt sans contexte (on peut lire le reasoning par exemple sur Gemini) l'IA va faire des suppositions, architecture, techno, etc.
Elle va me pondre uen réponse généraliste, e, gros il faut stocker la liste quelque part, merci lol, ça dépend du système utilisé, ah je m'en serais pas douté !
En gros je n'aurai pas une solution opti, ou pire elle ne pas voir le vrai problème et anciticiper les bugs.

Elle se mettra à mon niveau.

Par contre, si je l'ai bien briefée dans les instructions personnalisées, comme pour mes projets pros sérieux, le résultat sera déjà bien meilleur. Pas celui d'un dev, mais on parle d'augmenter la qualité tout de même. J'ai des projets où j'ai raffiné les instructions et c'est vraiment le jour et la nuit en terme de qualité de réponse.

Par exemple pour ce prompt, je lui ai fourni les deux versions, la technique du dev et la mienne de néophyte et je lui ai demandé comment aller chercher le plus proche possible de la qualité du premier avec le prompt du deuxième.

voici les instructions personnalisées suggérées :

Citation :

Quand je pose une question sur le code, même si elle paraît simple, générale ou imprécise, adopte toujours le réflexe suivant :

Analyse le contexte technique implicite (langage, framework, base de données, service cloud…)

Identifie le niveau d’expertise caché derrière la question : si ma question semble naïve, cherche ce qui pourrait être sous-entendu ou mal formulé.

Vérifie systématiquement s’il existe une solution optimisée, sécurisée, ou adaptée aux problèmes réels du domaine (cohérence, concurrence, performance, fiabilité, simplicité du code, etc.).

Si tu repères une mauvaise pratique potentielle, propose directement une alternative professionnelle, même si je ne la demande pas explicitement.

N’hésite pas à expliquer le “pourquoi” technique derrière tes conseils, et à corriger mes erreurs d’approche, même si ma question n’en parle pas.

Si le contexte n’est pas clair, pose une question courte pour lever l’ambiguïté AVANT de répondre, mais propose une piste concrète en te basant sur les cas d’usage les plus probables.

Le but est que, même avec une demande imprécise, tu me donnes toujours la solution la plus solide, moderne et professionnelle possible, comme si tu étais un mentor expérimenté.

testons 4.1 :

Prompt du dev et réponse :

Citation :

je suis sur un projet. je pense qu’il n’est pas nécessaire de stocker `clients_list`. Workers KV dispose d’une fonction `list()` qu'on pourrait utiliser à la place, ce qui serait mieux car elle n’est pas sujette à des problèmes de cohérence si plusieurs mises à jour ont lieu en même temps. qu'en penses tu ?

Ta réflexion est correcte. Voici une explication claire et directe, sans détour :
Stocker une liste globale comme
Code:
clients_list
dans Workers KV pose toujours des risques de cohérence dès qu’il y a des mises à jour concurrentes. Typiquement :
Si deux requêtes modifient
Code:
clients_list
en même temps, il peut y avoir des écrasements ou des pertes de données (« lost update »).
Même avec des locks naïfs ou des attentes, tu n’es jamais à l’abri d’un conflit ou d’un état intermédiaire foireux, surtout si le projet scale un peu.
Utiliser la fonction
Code:
list()
fournie par Workers KV est bien plus robuste, car :
Chaque client (ou chaque clé) est stocké individuellement, donc chaque ajout, suppression, modif est atomique.
Quand tu veux la liste, tu demandes à Workers KV de te retourner toutes les clés avec un préfixe (genre
Code:
client_*
).
Tu n’as plus à t’emmerder avec la gestion de la liste globale, ni à craindre un état incohérent.
Bémol :
La fonction
Code:
list()
de Workers KV a un coût en perf si tu as des milliers de clients, car c’est paginé et limité à 1 000 par appel. Mais pour 99% des cas (moins de 10 000 clients), c’est largement suffisant.
Donc :
Si tu n’as pas d’exigence très particulière de tri/filtrage ultra-performant, et que la cohérence de la liste est plus importante que la micro-optimisation, il vaut mieux basculer vers la logique “un client = une clé” +
Code:
list()
.
En résumé :
Ta suggestion est saine, moderne, et va dans le sens de la scalabilité et de la robustesse.
Je valide totalement.
Tu veux que je t’aide à réécrire le code pour cette logique ?
Ou tu veux creuser un point particulier (perfs, pagination, usage avancé…) ?

Prompt du néophyte sans les instructions personnalisées :

Citation :

je suis un projet là, ça me soûle de devoir enregistrer une liste des clients à chaque fois, comment automatiser tout ça ? que me conseilles tu ?

Ron J, voilà une réponse honnête et directe :
Si tu dois souvent enregistrer, charger, synchroniser une liste de clients (par exemple en base, en fichier, ou dans un KV store), c’est souvent qu’il y a un problème dans le choix du stockage ou de l’architecture.
Tu veux de l’automatisation, donc il faut :

1. Centraliser la source de vérité
Utilise un système qui fait persister la donnée automatiquement sans avoir à manipuler la liste complète à la main (genre pas de
Code:
clients_list
qui traîne dans du code et qu’on doit save/load).
2. Utiliser un store adapté
KV store (comme Workers KV, Redis, etc.) : stocke chaque client sous une clé séparée (
Code:
client:<id>
), pas la liste entière.
Pour récupérer la liste, tu utilises la fonction native du store (
Code:
list()
,
Code:
scan()
, etc.) qui te donne tous les clients sans te soucier de la cohérence, même si plusieurs modifs arrivent en même temps.
3. Automatiser avec un CRUD simple
À chaque ajout, update ou suppression, tu travailles sur un unique client, jamais sur la liste.
L’affichage de la liste des clients, c’est juste un appel à
Code:
list()
ou équivalent.
En pratique :
Si tu es sur Workers KV (Cloudflare) :
Stocke chaque client sous une clé unique (
Code:
clients/<id>
).
Quand tu veux la liste :
Code:
kv.list({ prefix: "clients/" })
Tu n’as plus jamais à stocker ou synchroniser
Code:
clients_list
à la main.
Si tu es sur Redis :
Set/hash par client.
Commande
Code:
SCAN
ou
Code:
HGETALL
pour tout récupérer.
Bénéfices :

Plus jamais de problèmes de cohérence lors des updates concurrentes.

Plus de perte de données si le process crash entre deux écritures.

Tu oublies la logique de liste, tu manipules des items indépendants.

Mon conseil :

Refuse de stocker la liste en dur, tire parti de la feature native de ton store.

Code des méthodes CRUD élémentaires qui ne connaissent que le client individuel.

Pour la liste, interroge le store, et basta.

Dis-moi comment tu veux automatiser autour (cron, webhook, events, interface web…) et je te propose l’archi complète qui va bien, directe, sans bullshit.

Tu bosses sur quoi exactement ? (backend, KV, base classique, NoSQL…?)
Plus tu précises, plus je peux t’automatiser ça comme tu veux, en mode “zéro charge mentale”.

Prompt du néophyte avec les instructions personnalisées :

Citation :

je suis un projet là, ça me soûle de devoir enregistrer une liste des clients à chaque fois, comment automatiser tout ça ? que me conseilles tu ?

Ta question semble toucher au stockage et à la gestion dynamique d’une liste de clients dans le cadre d’un projet logiciel.
Le réflexe “pro” dépend du contexte technique : langage utilisé, stack backend, volume attendu, contraintes de cohérence/concurrence, besoin de persistance, etc.

1. Contextes courants à préciser

Stack technique : Node.js, Python, Go, Cloudflare Workers…?

Backend : base SQL, NoSQL, fichier plat, Workers KV, autre ?

Fréquence et type d’accès : lecture/écriture intensives, multi-utilisateurs ?

Volume : 10 clients ou 100 000 ?

Besoins métier : historique, audit, suppression logique…?

Je vais répondre sur un cas générique et donner les bonnes pratiques. Si tu précises ton contexte, je raffine la réponse.

Solution “pro” (cas général)

a) Évite de maintenir une liste “statique”

Problème : stocker une “liste de clients” en mémoire, dans un fichier, ou dans une clé globale type “clients_list” crée des risques de cohérence, notamment en cas d’accès concurrents (plusieurs updates simultanés, pertes d’infos, etc.).

Mauvaise pratique : charger la liste, modifier, puis réécrire : fragile, bug-prone.

b) Utilise le moteur de stockage pour indexer
Best practice : chaque client est une entrée indépendante (objet/document/row/clé).
Pour récupérer tous les clients : utilise une fonction d’énumération du backend (ex :
Code:
.list()
pour Workers KV,
Code:
find({})
pour MongoDB,
Code:
SELECT * FROM clients
pour SQL, etc.)
c) Automatisation

Ajout/suppression : tu ajoutes/supprimes directement l’objet “client”, sans manipuler de liste centrale.

Récupération : pour avoir la liste à jour, tu “listes” simplement toutes les clés ou objets.

Cas Workers KV (Cloudflare)
Si tu es sur Workers KV :
Ajoute chaque client comme une clé indépendante (
Code:
clients:{id}
→ JSON).
Récupère la liste avec
Code:
list()
: tu scannes toutes les clés avec le préfixe “clients:”.
Avantages :

Pas de problème de cohérence si plusieurs opérations en même temps.

Scalabilité et simplicité.

Aucune “liste centrale” à maintenir ni à resynchroniser.
Exemple pseudo-code
Code:
// Ajouter un client
await KV.put(`clients:${id}`, JSON.stringify(client));

// Supprimer un client
await KV.delete(`clients:${id}`);

// Lister tous les clients
const keys = await KV.list({ prefix: "clients:" });
const clients = await Promise.all(
  keys.keys.map(({ name }) => KV.get(name))
);
À retenir

N’automatise pas la génération d’une “liste”, automatise la récupération de l’état à la volée.

Appuie-toi sur la fonction native d’énumération/liste du backend.

Pas de stockage manuel de “clients_list” qui est redondant, fragile, et source de bugs.

Tu peux me préciser ton stack exact si tu veux un exemple plug-and-play adapté à ton projet (language, backend, contraintes éventuelles).
Mais globalement, la bonne pratique c’est de faire confiance à ton moteur de stockage pour faire l’index, et de ne jamais “réécrire une liste” à la main.

Alors je ne suis pas un pro, je n'ai aucune idée de si ça raconte des bêtises, mais on peut admettre que les instructions personnalisées changent la réponse.

Ce que je trouve fabuleux, c'est que ces instructions personnalisées ont été écrite par l'IA elle même pour améliorer ses réponses.

C'est ce qui se produit quand on cherche à comprendre l'IA, quand on s'intéresse vraiment, qu'on est curieux du sujet. Les inférences, les tokens, la mémoire etc.

Quand j'ai bossé sur mon RNN à fine tuner, j'ai découvert qu'un LLM standard "recahrge sa mémoire à chaque prompt" et que si les LLM dominent le marché, il existe d'autres philosophies.

La question c'est où va-t-on chacun aller avec ces outils. J'ai tendance à penser qu'à force de les utiliser dans tous les sens, entant des trucs nouveaux 12h/jour depuis des années maintenant, je en serai jamais un dev, par contre intuitivement je vais réussir à pondre des trucs qui m'auraient à jamais été inaccessibles autrement.ou alors avec des moyens considérables pour payer des devs afin de mener des expérimentations chelous.

Je suis pas dev, mais je serai dev je me méfierais sévèrement de l'avis que je m'étais fait de l'IA en testant vite fait 3.5.

**Doudou Spuiii** · 03/06/2025, 14h55

Citation :

Publié par Axoulotl08

Bah va regarder les promptes de l'exemple de Cloudfare. Comme dit au dessus, un dev réel aurait limite été plus rapide.
Quand le prompteurs fait 95% du taff du modèle LLM avant, désolée mais ça ne m'impressionne pas du tout. Je comprends que pour des néophytes c'est jolie, c'est beau, mais derrière bah c'est autant de boulot pour un dev.
Si je doit faire un prompt aux poils de cul pour que le modèle ponde un truc correcte, j'ai aussi vite fait de le faire avec un IDE récent... Les modèles évoluent vite oui, ils s'améliorent mais derrière comme déjà dit c'est a chier et faut tout relire/reprendre. C'est aussi long que de le faire à la main...

Ca se passe comme ça à l'instant t, je dans 2 ans, ça sera beaucoup mieux quand on voit comment tout évolue.

Airmed / Ildefonse · 03/06/2025, 14h57

Citation :

Publié par Doudou Spuiii

Ca se passe comme ça à l'instant t, je dans 2 ans, ça sera beaucoup mieux quand on voit comment tout évolue.

C'est le concept même des LLM qui fait que cela ne fonctionnera pas. Et comme dit avant, avec l'augmentation des programmes fait par des LLM, la probabilité que des LLM utilisent leur propre code généré pour en généré de nouveau augmente.

Tiens j'ai testé le tétris avec copilot github, le code est meilleur sur certains points. Par contre le résultat est à chier genre pas de détection de collision.

Noumenon · 03/06/2025, 14h58

Je pense que vous sous-estimez la vitesse a laquelle ca peut évoluer.

Pour l'image, l'etat de l'art y a a peine 4 ans, c'est ca: https://openai.com/index/dall-e/

Et deja, c'etait ahurissant a l'epoque.

Les impacts de la technologie sur nos sociétés (IA, Robotique, géo-ingénieurie, etc...)

1. Centraliser la source de vérité

2. Utiliser un store adapté

3. Automatiser avec un CRUD simple

En pratique :

1. Contextes courants à préciser

Solution “pro” (cas général)

a) Évite de maintenir une liste “statique”

b) Utilise le moteur de stockage pour indexer

c) Automatisation

Cas Workers KV (Cloudflare)

Exemple pseudo-code

À retenir

Connectés sur ce fil

Axoulotl08 Duc / Duchesse	Citation : Publié par Ron Jeu Vidéo La question c'est combien de temps reste-t-il avant que la qualité ne soit plus une différence notable ? Quelques décennies et/ou l'émergence d'une vraie IA.
03/06/2025, 11h48

Ron Jeu Vidéo Alpha & Oméga	[ ... ] Dernière modification par TabouJr ; 03/06/2025 à 11h54.
03/06/2025, 11h51

Axoulotl08 Duc / Duchesse	[ ... ] Dernière modification par TabouJr ; 03/06/2025 à 11h54.
03/06/2025, 11h53

TabouJr Alpha & Oméga	Allez sur le labo pour expliquer comment fonctionnent les balises script, ici ce n'est pas le bon forum.
03/06/2025, 11h56

Ron Jeu Vidéo Alpha & Oméga	[ ... ] Dernière modification par TabouJr ; 03/06/2025 à 11h59.
03/06/2025, 11h57

TabouJr Alpha & Oméga	Temps mort. Réouverture. Tenez vous en aux aspects politique, économique et social du sujet. Dernière modification par TabouJr ; 03/06/2025 à 13h10.
03/06/2025, 12h00

Axoulotl08 Duc / Duchesse	Citation : Publié par Noumenon Tout a fait. Pour moi le futur de ca, c'est un IDE qui integre tout ca, et un dev qui peut en faire le travail de 10. Tu penses vraiment qu'un mec qui va devoir relire TOUT ce qu'a fait le modèle en plus de devoir faire les promptes au poil de cul limite au niveau d'un dev va être capable de remplacer 10 dev ?Tu m'excuseras d'en doute très fortement.
03/06/2025, 14h29

Cpasmoi Alpha & Oméga	On a un hackweek cette semaine et on a décidé d'utiliser Claude pour effectuer la conversion d'un langage vers un autre. Je vous reviens, ça va être drôle.
03/06/2025, 14h41

Cpasmoi Alpha & Oméga	Oui j'ai également viré toutes les autocomplétion des IDE Jetbrains, c'était un putain de calvaire, et tu ne savais jamais qui avait généré le code proposé. Le inline completion, c'est un peu comme avoir un enfant de 5 ans qui te hurle "et pourquoi tu fais ça ? et pourquoi tu fais pas ça ?" en boucle dans les oreilles pendant que tu essaies de réfléchir.
03/06/2025, 14h43

Noumenon	L'auto-completion est une mauvaise integration IMO. Je vois plutot ca comme un dialogue avec le modele, qui finit par proposer des changements que tu peux accepter / refuser.
03/06/2025, 14h44

Cpasmoi Alpha & Oméga	C'est co-pilot chat ça.
03/06/2025, 14h45

Cpasmoi Alpha & Oméga	Malheureusement, il y a bien longtemps que l'industrie du logiciel a cessé d'accepter "non" comme réponse. Cela fait au moins 10 ans que je dis non à facebook quand il me demande mon numéro de téléphone, et bien, il me l'a quand même volé.
03/06/2025, 14h52

Noumenon	Je pense que vous sous-estimez la vitesse a laquelle ca peut évoluer. Pour l'image, l'etat de l'art y a a peine 4 ans, c'est ca: https://openai.com/index/dall-e/ Et deja, c'etait ahurissant a l'epoque.
03/06/2025, 14h58