Forum Linux.général Quels outils utilisez-vous pour générer du code rapidement grâce à l’IA ?

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
1
15
août
2025

Salut à tous,

Vous arrive-t-il d’avoir un petit bout de code à écrire — rien de sorcier, juste un script bash pour renommer 200 fichiers ou un petit module Python pour parser du JSON — et de vous dire : « Franchement, si quelqu’un pouvait me pondre ça à ma place, je ne dirais pas non » ?

Récemment, j’ai testé quelques assistants IA pour ce genre de tâches. Résultat :

Le code sort en quelques secondes, souvent propre… et parfois avec un bonus de commentaires (parfois utiles, parfois poétiques).

Ça m’a évité pas mal de copier-coller depuis des vieux projets poussiéreux.

MAIS… il faut relire et tester, sinon vous risquez de découvrir un while true surprise à 2 h du matin.

Du coup, je suis curieux :

Vous utilisez quoi dans ce domaine ? Copilot ? ChatGPT ? Des outils libres ?

Vous leur confiez seulement du “boilerplate” ou aussi des parties plus critiques ?

Vous avez déjà eu un moment magique… ou complètement WTF avec un bout de code généré par l’IA ?

Je me dis que si on met nos expériences en commun, on pourra peut-être tous gagner du temps… ou au moins éviter les mêmes pièges. 😄

— Un utilisateur qui aime Linux, mais pas retaper 15 fois la même boucle for

  • # non

    Posté par  (site web personnel) . Évalué à 10 (+14/-6).

    renommer 200 fichiers

    rename(1)

    parser du JSON

    jq

    Je comprend pas l'intérêt de rajouter une tonne de merde autogénérée à sa codebase.

    pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

  • # LocalLLaMA

    Posté par  (site web personnel) . Évalué à 8 (+7/-0).

    Salut.

    J'utilise des logiciels libres et des modèles "ouverts" (téléchargeables sur huggingface par exemple) que je peux faire tourner sur ma/mes machine(s). En ce moment j'utilise beaucoup Qwen3-Coder-30B-A3B-Instruct-GGUF.

    Pour lancer un LLM j'utilise llama.cpp
    Pour pouvoir passer d'un modèle à un autre llama-swap

    J'utilise surtout VSCodium avec l'extension continue qui permet d'avoir un chat à côté de l'éditeur.

    Etant donné que ceci fonctionne en local je peux lui confier tout dans la limite du contexte possible avec la machine sur laquelle il fonctionne.

    Moment magique : quand un LLM m'a sorti la bonne réponse à une obscure question pour un cas très particulier en 2 prompts alors que j'avais cherché un moment sur Internet sans parvenir à trouver la réponse. Je crois que c'était un modèle Mistral.

    Pour la veille je suis ce qui se passe sur /r/LocalLLaMA/

    wind0w$ suxX, GNU/Linux roxX!

    • [^] # Re: LocalLLaMA

      Posté par  . Évalué à 4 (+3/-0).

      +1 pour Qwen3-Coder-30B-A3B, les modèles Qwen3 sont probablement la meilleur familles de modèles à l'heure actuelle pour l'usage local (en terme de rapport qualité/rapidité).

      C'est dommage pour Mistral puisqu'ils ont inspirés ce genre de modèles avec Mixtral-8x7B mais qu'ils n'ont pas persévéré, alors que Qwen a poussé la logique de l'architecture MoE à fond (sous-modèles très petits et rapides), et ils obtiennent des modèles exceptionnels et étonnamment peut médiatisés en dehors de l'engouement sur HuggingFace.
      D'ailleurs OpenAI a suivi le même chemin avec gpt-oss…

      Pour le développement Python, j'utilise Pycharm avec l'extension ProxyAI. Il suffit ensuite de configurer la connexion sur un serveur de type "custom OpenAI".
      Sur OSS Code j'utilise Cline pour l'assistance mais j'ai jamais cherché à faire du vibe-coding, ça m'a l'air superflus pour l'usage que j'en ai.

      • [^] # Re: LocalLLaMA

        Posté par  (site web personnel) . Évalué à 3 (+1/-0).

        Merci pour ces retours instructifs. Par curiosité, quelle config matérielle vous avez pour arriver à faire tourner ces trucs ? Et les résultats sont globalement suffisament pertinent ?

        J'ai fait quelques expériences avec Ollama, sans arriver à obtenir des réponses vraiment satisfaisantes, et tout ça en freezant l'ordi… je n'ai pas fini d'expérimenter mais j'en suis à me demander si le souci vient de mes choix (de modèles, de logiciels, de tout ce que je n'ai pas compris), s'il faut forcément un ordi de folie pour arriver à quelque chose, et si on peut réellement espérer approcher "en local" le niveau de réponse des géants des LLM. Je suis donc hyper intéressée par les retours d'autres utilisateurs.

        • [^] # Re: LocalLLaMA

          Posté par  (Mastodon) . Évalué à 6 (+3/-0). Dernière modification le 16 août 2025 à 16:55.

          Par curiosité, quelle config matérielle vous avez pour arriver à faire tourner ces trucs ?

          Alors là je suis un peu esplanté… J'avais jamais trop joué avec l'IA en local et du coup je suis la conversation.

          J'avais entendu dire que ollama c'est top pour essayer en local.

          J'installe ollama, je trouve la commande à taper pour faire tourner le modèle en question. Je le fais tourner sur un laptop certes bien couillu (Core i7 Ultra, 92Go de RAM), mais sans carte graphique (j'ai un warning de ollama comme quoi je vais tourner sur le CPU) et voici le résultat : https://asciinema.org/a/EcUlDaMkBmnEH1k6R3xTArYeT

          C'est clairement utilisable !

          et tout ça en freezant l'ordi

          De ce que je vois ollama va charger en RAM l'intégralité du modèle, 20Go dans le cas de ce modèle. Donc faut de la RAM, je pense que dans tes essais tu devais swapper.

          En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

        • [^] # Re: LocalLLaMA

          Posté par  . Évalué à 2 (+1/-0). Dernière modification le 17 août 2025 à 16:55.

          Je connais ollama que de nom, j'ai jamais utilisé.
          Je passe par vllm pour mon propre serveur dédié et llama.cpp en complément sur ma machine de travail (ollama est basé sur llama.cpp).
          Donc je connais pas le détail pour ollama, mais llama.cpp permet de spécifier le nombre de couches du modèle sur le GPU.
          Cela permet de faire tourner des modèles qui ne rentrent pas dans ta VRAM en utilisant la mémoire centrale (au prix d'un ralentissement de l'ensemble).

          Sur llama.cpp, cela se règles avec des paramètres tels que:
          --n-gpu-layers (nombre de couches sur GPU)
          --tensor-split (si tu as plusieurs GPU)
          --ctx-size" (taille du contexte. Plus tu réduis la taille du contexte moins tu auras besoin de mémoire, mais si ta machine a les capacités, mets la valeur maximale supportée par le modèle).

          En local, j'ai deux GPU de 16 Go, donc ça me permet de charger des modèles jusqu'à environ 30 milliards de paramètres avec une taille de contexte raisonnable après quantification en Q4_K_M (typiquement ce que propose ollama généralement).

          Le problème de ollama, c'est que c'est conçu pour être une solution simple et générique, mais c'est plus compliqué pour adapter à des cas particuliers (comme le déchargement sur la mémoire centrale ou définir la taille de contexte). Et pour être compatible avec un maximum de configuration, ils définissent souvent une taille contexte très petite (4096), alors que beaucoup de modèles actuels supportent jusqu'à 128K tokens, voir plus.

          Si tu veux pas te prendre la tête à passer directement par llama.cpp et/ou que tu ne sais pas comment t'y retrouver parmi tous les modèles, je te conseille une interface comme lm-studio.
          L'interface est bordélique, c'est une application Electron type avec une l'ergonomie douteuse (je déteste ça). Par contre c'est très complet.

          Sinon tu peux simplement télécharger le modèle directement:
          https://huggingface.co/lmstudio-community/Qwen3-Coder-30B-A3B-Instruct-GGUF/tree/main (je conseille Qwen3-Coder-30B-A3B-Instruct-Q4_K_M.gguf)

          Si tu veux dans un premier temps expérimenter, prends des mini modèles:
          https://huggingface.co/lmstudio-community/Qwen3-0.6B-GGUF/tree/main
          https://huggingface.co/lmstudio-community/Qwen3-4B-Instruct-2507-GGUF/tree/main (petit mais loin d'être ridicule)

          Et lancer une serveur compatible OpenAI en local avec llama-serveur (de llama.cpp):
          llama-server --model Qwen3-Coder-30B-A3B-Instruct-Q4_K_M.gguf --jinja --n-gpu-layers 1000 --port 8080 --alias default --ctx-size 24000

          Maintenant tu peux t'y connecter avec tout client qui permet de définir manuellement le point d'entrée pour OpenAI (ici http://127.0.0.1:8080/v1/chat/completions, modèle 'default').

          Si tu connais pas, tu peux être perdu au début (surtout avec tous ces modèles, leur quantification et leurs variantes), mais les outils ne sont pas si complexes et c'est facile de se créer des scripts bash qui vont bien une fois que tu as trouvé ton bonheur.

          • [^] # Re: LocalLLaMA

            Posté par  (site web personnel) . Évalué à 2 (+0/-0).

            Merci, ça me donne d'autres pistes pour mes expérimentations. Mon ordi va clairement limiter mes tests (je n'ai "que" 16 Go de Ram, le reste est à l'allant, ce qui suffit par ailleurs donc je ne vais pas upgrader pour le moment), mais c'est assez pour comprendre peu à peu comment tous ces trucs s'articulent. Vu les retours ici, faut que je teste llama.cpp :)

            Avec l'enshittification des recherches web, je n'ai pas vraiment trouvé de bons tutos pour mettre ce genre de truc en place, je tâtonne pas mal. Typiquement, quel modèle tester, avec quel outil… Comme souvent quand on est néophyte, la difficulté est d'acquérir suffisament de vocabulaire et de référence pour savoir ensuite quoi creuser ; lire la doc, ok, mais laquelle ? Là je commence à être au niveau où "Q4_K_M" et "le nombre de tokens" ont un peu de sens pour moi mais il y a encore du taf avant que je comprenne les détails. Si on trouve des modèles à 7B voir 1.5B c'est que ça doit avoir une utilité, par exemple, mais jusque là mes tests avec ces modèles me donnent l'impression que n'importe quel Eliza est plus efficace (et moins compliqué à faire tourner).

            Voir vos retours avec des 30B qui sont utilisables, c'est plus encourageant. Et savoir sur quelles machines ça tourne… ok, ce n'est pas pour moi pour le moment mais j'ai quelqu'un dans mon entourage qui a ce genre de machine, je lui emprunterais à l'occasion :D

            • [^] # Re: LocalLLaMA

              Posté par  . Évalué à 2 (+1/-0).

              Les petits modèles ont deux utilités, tester une architecture avant de dépenser beaucoup d'énergie pour entraîner des modèles plus gros.
              Sinon répondre à des besoins précis (via le fine-tuning) avec des modèles spécialisés économes en ressources.

              Si tu prends un modèle comme Qwen3-4B, tu peux typiquement le faire tourner sur un téléphone haut de gamme.
              Donc si tu as un GPU avec au moins 6 Go de vram, ça devrait pas être un problème à faire tourner sur ta machine.

              Faut savoir qu'avoir 16 Go de Ram c'est bien, mais si tu peux avoir cette mémoire dans ton GPU c'est mieux niveau performances, et de loin !
              Si un jour tu décides d'acheter un GPU avec l'idée de faire ton propre ChatGPT, penses que dans ce cas d'usage la quantité de mémoire disponible sera toujours plus importante que la puissance de calcul (ne te fais pas influencer pas les comparatifs et autre benchs qui sont orientés jeux vidéos).

              Parce que tu peux avoir le GPU le plus puissant du monde, les performances s'effondreront si tu es obligé de faire tourner en partie le modèle sur la mémoire centrale.
              Plus tu as de vram, plus tu aura un large choix de modèles, et plus ils seront potentiellement qualitatifs.

              Si tu prends la famille des Qwen3-30B-A3B, ils sont calibrés pour pouvoir être utilisés avec 24 Go de vram une fois quantifié en 4 bits par poids, mais avec une taille de contexte relativement petite (~16K hors optimisation type flash attention).
              Donc plus tu auras de mémoire en plus, plus tu auras du confort d'utilisation, surtout si tu veux t'en servir comme assistant de travail (code, écriture, rédaction d'articles, etc…).

  • # Code méthode David Goodenough avec limiteur par emmerdemment

    Posté par  (site web personnel) . Évalué à 10 (+8/-0). Dernière modification le 15 août 2025 à 10:01.

    Un utilisateur qui aime Linux, mais pas retaper 15 fois la même boucle for

    Je suis plutôt du genre à retaper 15 fois la boucle for, puis à force ça m'ennuie alors je scripte (ou je finis par découvrir une commande qui fait plus/mieux). Je lance 15 fois le script. Puis je me décide à l'améliorer/mieux l'intégrer/le compléter. Alors je lance 15 fois…

    Mais je n'ai pas appris à faire des boucles ou des scripts en demandant à l'IA de les faire à ma place, mais en cherchant/voyant comment les autres faisaient, comment la doc disait, en faisant des commandes/scripts merdiques ou bogués, par répétition et alternance succès/échec, ce qui diffère de l'apprentissage actuel de quelqu'un a qui on met à dispo une ange gardien virtuel (plus ou moins compétent et fiable) dès le départ

    Exemple typique : la rétrospective de la quinzaine, d'abord très à la main, puis des séries de commandes shell enrichies en pipe et en ssh, puis des séries de scripts… un jour peut-être un script qui lancera tout en une commande, quand j'en aurais suffisamment marre et que coder ça sera la meilleure excuse pour ne pas faire un autre truc plus urgent/important.

    (Nb: le "David Goodenough" n'est pas ici sur la qualité du code mais sur la résistance à la répétition de la personne qui code)

  • # Benchmark possible ? Valeur indicative de vitesse ?

    Posté par  . Évalué à 4 (+3/-0).

    Suite à la présentation d'un collègue sur l'utilisation de Ollama et d'autres outils d'IA open source, je me suis laissée tenter par l'installation de Ollama avec un jeu de données de 65Go (model 120b …..)

    J'ai voulu me rendre compte si cela était réellement multithread, donc j'ai mis ça dans une vm sur mon homelab. C'est un vieux Prolian DL360G9, avec bi CPU E5-2695 V4. 77 thread alloué à la vm et 150 Go de ram (je croyais que le modèle 120b prenait 120Go de ram).

    J'ai lancé quelques prompt et là, je me suis dit : ok c'est bien joli tout ça, ça turbine sur tous les thread, mais le retour est-il réellement rapide (c'est juste un serveur avec du cpu). Ce type de serveur peut-il me rendre service avec de l'utilisation d'IA ponctuellement ?

    Et donc mon questionnement est : c'est quoi que l'on entend par "rapidement" sur le retour d'une IA ? Y a t-il une valeur que l'on peut utiliser pour comparer des machines/services, que ce soit dans le cloud ou en local.

    A une époque, on faisait des benchmark de CPU, on regardait la rapidité de calcul de Pi, on regardait le nombre de fps, etc (surtout quand on cherchait les limites d'overcloaking, le bon vieux temps).

    Mais là, pour l'IA c'est quoi la valeur à suivre ? La rapidité à laquelle l'IA répond, rapidité d'affichage des caractères dans la formulation de la réponse ? Le nombre de token utilisé ? (je vois qu'en local, en verbeux, ollama donne ce type d'info en fin de réponse).

    Je suis preneur de vos réponses, et ça aidera peut être à répondre au sujet par ricochets 🤓🤓

    • [^] # Re: Benchmark possible ? Valeur indicative de vitesse ?

      Posté par  . Évalué à 3 (+2/-0).

      Des métriques, il y a en a tout un tas, ça dépends de ce que tu cherches.
      Tu prends l'exemple des FPS, mais avec les llm le nombre de tokens par secondes est tout aussi pertinent.

      Maintenant le temps de génération global est également dépendant de la longueur de la génération, surtout que tu as l'air d'utiliser gpt-oss (déduction puisque 120b et dernier modèle à la mode…), qui est un modèle de raisonnement.
      Ce genre de modèle a une première étape de génération de "raisonnement" et ensuite de génération de la réponse finale, qui peut potentiellement n'être générée qu'à partir de 200, 300 tokens ou plus. Donc c'est certain que ça créé de la latence.

      Le truc c'est que c'est spécifique à chaque modèle (la verbosité du raisonnement de gpt-oss peut être configuré, mais c'est le seul à faire ça, Qwen3 à côté est soit hyper verbeux, soit répond directement sans raisonnement). Et les instructions que tu spécifies au modèle ont également une incidence.
      Donc non, il n'y a pas de barème magique pour comparer simplement tout ce monde là, car tous les modèles sont différents et beaucoup de modèles ont des domaines d'application privilégiés (dans l'absolu un modèle petit et performant mais verbeux pourrait donner des réponses plus lentement qu'un modèle plus lourd mais concis).
      On compare généralement la qualité des réponses par domaines plus ou moins généraux, les capacités linguistiques, techniques, et la factualités.
      Et pour la performance brute, le nombre de tokens à la seconde suffit, même si c'est pas forcément mis en avant parce que quand tu as l'habitude, le simple fait de connaître le nombre de paramètres actifs suffit à en avoir une idée approximative (en l’occurrence gpt-oss-120b, c'est 5,1 milliards de paramètres actifs par tokens, donc en théorie plus rapide qu'un modèle de seulement 8 milliards de paramètres tel que Llama-3.1-8B, même si des détails architecturaux et d'implémentation peuvent varier, dans les grandes lignes ça marche).

      J'ai par contre je n'ai jamais entendu parler d'un comparatif qui notait la concision des réponses.
      C'est dommage parce que ça serait une bonne chose que les llm soient les plus concis possible, le problème est qu'ils tendent à être moins précis et moins qualitatifs quand on leur impose d'écourter les réponses via des instructions…

      • [^] # Re: Benchmark possible ? Valeur indicative de vitesse ?

        Posté par  . Évalué à 2 (+1/-0).

        Merci beaucoup pour ta réponse. Ça répond très bien à mes interrogations. J'ai eu le même type de retour par mes collègues ce midi.

        J'imaginais pas que c'était aussi touffu 😁

        Et vu ton dernier passage, sur le nombre de paramètres par token, je comprends que ce soit quasi impossible d'avoir une comparaison valable hardware vs rapidité de résultats. Trop de paramètres différents rentre en compte. Je vais garder le nombre de token par seconde, comme valeur à suivre (piur ordre d'idées).

        Le modèle utilisé est bien celui que tu dis, je suis plus attiré par le hardware que le software et l'IA ne m'attire pas plus que ça (jsuis pas un créatif de base). Mais c'est intéressant de se dire que potentiellement, du vieux matos est largement suffisant pour une IA local, et comme me l'a dit un collègue, tout dépend du temps que chacun est prêt a attendre pour avoir une réponse 🤣

        J'imaginais l'IA "en général" en mode instantané (ou presque), d'où ma vision de comparaison comme des fps 😁😁😁

        Pour revenir au sujet du forum, l'échange ici semble montrer que mettre le terme "rapidement" comme critère n'est pas une bonne idee. Trop de paramètres peuvent rentrer en compte. C'est plutôt du tâtonnements personnel qui peut permettre de dire que tel modèle sur tel machine répond le mieux a son besoin.

        Bon courage dans tes recherches cbum63 🤓

  • # Commentaire supprimé

    Posté par  . Évalué à 1 (+0/-0). Dernière modification le 20 août 2025 à 10:20.

    Ce commentaire a été supprimé par l’équipe de modération.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.