Alors j’ai eu exactement le même scepticisme que toi au début. Surtout qu'il y a énormément de bullshit autour de l’IA en entreprise, avec des usages franchement absurdes. Je bosse sur des projets qui tournent sur des systèmes critiques. Si ça plante, faut pas que cela tue les gens qui sont autour ou dans le machin contrôlé par le système critique.
Par contre, réduire un LLM à "une techno statistique qui allonge des mots" me paraît aujourd’hui insuffisant pour décrire ce qui se passe réellement en pratique.
Alors oui, à la base c’est un modèle probabiliste et au début ça faisait vite de la merde au bout de quelques dizaines de lignes. Mais en pratique, on n’emploie pas du tout une IA comme une simple autocomplétion améliorée. On travaille avec un contexte contraint et structuré : règles de codage (MISRA pour ceux qui connaissent, guidelines internes de la boite, etc.), base de code existante, patterns imposés, contraintes d’archi, etc. Toute la génération est conditionnée par ça.
Et faut reconnaître que ça marche plutôt bien, les LLM actuels sont loin du cliché "ça génère du code au hasard".
Ca permet d'aller bien plus vite et avec moins d'erreurs sur :
la génération ET la revue de code qui respecte des conventions strictes (nommage, certains patterns de code essentiels qu'il faut respecter, contraintes safety dans la façon de faire le design de l'appli et d'implémenter).
l'identification de patterns de vulnérabilités, parfois plus finement que certains outils d’analyse statique classiques (notamment sur des logiques multi-fichiers ou implicites : les outils classiques sont vites largués dans un tel cas).
l'identification des incohérences entre les specs, les docs de design, le code, et les tests. Et pourtant les gars qui codent les tests ne sont pas les mêmes que ceux qui codent l'appli. Les LLM nous montrent des trous dans la raquette alors que pourtant on a déjà plein d'outils de vérification.
Truc important : l’usage du LLM est itératif, pas one shot.
Je m'explique : on ne lui demande pas une solution complète et correcte d’entrée.
On boucle : génération par le LLM, critique / modification manuelle si c'est rapide à faire, contrainte supplémentaire, et le LLM va reprendre le code selon nos corrections et critiques. Et là, l'IA devient un outil de transformation de code bien pratique et surtout rapide : ça permet d'aller bien plus vite que s'il avait fallu tout se cogner à la main et les habituelles erreurs d’inattention.
Sur des tâches comme les IHM ou tout ce qui est plomberie autour d’API bien définies, le gain est visible. Ca produit rapidement un squelette cohérent, et le dev se concentre sur les cas spécifiques. On est plus proche d’un accélérateur de prod que d’un générateur pipotron.
Sur des sujets plus ouverts comme des nouveaux widgets ou un comportement spécifique, ça ne remplace pas l'imagination humaine, on est bien d'accord ! Par contre, pour du prototypage rapide, c’est difficile de rivaliser avec l'IA. On va décrire un comportement pour obtenir une première implémentation puis on peut améliorer de façon incrémentale. Le cycle est nettement raccourci.
Dans ma boite, le LLM ne remplace pas l'expertise, il réduit le coût des transformations intermédiaires. On n'a licencié personne et même on embauche. Avant on demandait aux gens de savoir utiliser une suite bureautique et un IDE en plus de savoir faire des algos et coder, et ben en plus maintenant, faut savoir utiliser l'IA dans l'IDE.
[^] # Re: qu'est ce qui vous gêne ?
Posté par vpo . En réponse au journal [LinuxFr] Confiance, IA et contenu. Évalué à 5 (+4/-0).
Alors j’ai eu exactement le même scepticisme que toi au début. Surtout qu'il y a énormément de bullshit autour de l’IA en entreprise, avec des usages franchement absurdes. Je bosse sur des projets qui tournent sur des systèmes critiques. Si ça plante, faut pas que cela tue les gens qui sont autour ou dans le machin contrôlé par le système critique.
Par contre, réduire un LLM à "une techno statistique qui allonge des mots" me paraît aujourd’hui insuffisant pour décrire ce qui se passe réellement en pratique.
Alors oui, à la base c’est un modèle probabiliste et au début ça faisait vite de la merde au bout de quelques dizaines de lignes. Mais en pratique, on n’emploie pas du tout une IA comme une simple autocomplétion améliorée. On travaille avec un contexte contraint et structuré : règles de codage (MISRA pour ceux qui connaissent, guidelines internes de la boite, etc.), base de code existante, patterns imposés, contraintes d’archi, etc. Toute la génération est conditionnée par ça.
Et faut reconnaître que ça marche plutôt bien, les LLM actuels sont loin du cliché "ça génère du code au hasard".
Ca permet d'aller bien plus vite et avec moins d'erreurs sur :
la génération ET la revue de code qui respecte des conventions strictes (nommage, certains patterns de code essentiels qu'il faut respecter, contraintes safety dans la façon de faire le design de l'appli et d'implémenter).
l'identification de patterns de vulnérabilités, parfois plus finement que certains outils d’analyse statique classiques (notamment sur des logiques multi-fichiers ou implicites : les outils classiques sont vites largués dans un tel cas).
l'identification des incohérences entre les specs, les docs de design, le code, et les tests. Et pourtant les gars qui codent les tests ne sont pas les mêmes que ceux qui codent l'appli. Les LLM nous montrent des trous dans la raquette alors que pourtant on a déjà plein d'outils de vérification.
Truc important : l’usage du LLM est itératif, pas one shot.
Je m'explique : on ne lui demande pas une solution complète et correcte d’entrée.
On boucle : génération par le LLM, critique / modification manuelle si c'est rapide à faire, contrainte supplémentaire, et le LLM va reprendre le code selon nos corrections et critiques. Et là, l'IA devient un outil de transformation de code bien pratique et surtout rapide : ça permet d'aller bien plus vite que s'il avait fallu tout se cogner à la main et les habituelles erreurs d’inattention.
Sur des tâches comme les IHM ou tout ce qui est plomberie autour d’API bien définies, le gain est visible. Ca produit rapidement un squelette cohérent, et le dev se concentre sur les cas spécifiques. On est plus proche d’un accélérateur de prod que d’un générateur pipotron.
Sur des sujets plus ouverts comme des nouveaux widgets ou un comportement spécifique, ça ne remplace pas l'imagination humaine, on est bien d'accord ! Par contre, pour du prototypage rapide, c’est difficile de rivaliser avec l'IA. On va décrire un comportement pour obtenir une première implémentation puis on peut améliorer de façon incrémentale. Le cycle est nettement raccourci.
Dans ma boite, le LLM ne remplace pas l'expertise, il réduit le coût des transformations intermédiaires. On n'a licencié personne et même on embauche. Avant on demandait aux gens de savoir utiliser une suite bureautique et un IDE en plus de savoir faire des algos et coder, et ben en plus maintenant, faut savoir utiliser l'IA dans l'IDE.