Dans Ratatouille, le chef Gusteau pense que la cuisine devrait être ouverte à tous. Remy est moins convaincu : savoir cuisiner ne signifie pas nécessairement qu’il faut laisser n’importe qui se lancer seul dans une cuisine. Leur bref échange capture une tension qui semble désormais familière dans le développement logiciel.
Donnez à quelqu’un un assistant de programmation IA, et cette personne peut transformer une idée en application fonctionnelle. Un tableau de bord. Un portail client. Une automatisation qui élimine des heures de travail répétitif.
C’est une opportunité remarquable. Les personnes qui comprennent un problème métier peuvent participer directement à sa résolution, même si elles ne se sont jamais considérées comme des développeurs.
Mais une application fonctionnelle n’est que le début d’une responsabilité.
Quelqu’un doit toujours décider où ses données doivent être stockées, qui peut y accéder, comment les changements arrivent en production et ce qui se passe lorsqu’un problème survient. Quelqu’un doit s’assurer qu’elle s’intègre aux systèmes, aux politiques et aux méthodes de travail de l’entreprise.
Tout le monde peut préparer un plat. Un restaurant a besoin de toute une cuisine derrière lui.
Quand une expérience devient essentielle
Prenons un scénario.
Un collaborateur veut trouver une meilleure façon de suivre les demandes des clients. Avec un assistant de programmation IA, il crée une petite application. Elle est réussie, fait gagner du temps et séduit rapidement quelques collègues.
Il la connecte aux données réelles des clients. Il ajoute un processus en arrière-plan pour maintenir toutes les informations à jour. Pour la rendre accessible, il partage un lien.
En quelques semaines, l’équipe en dépend.
Mais l’application s’exécute sur l’ordinateur portable du collaborateur. Son intégration utilise des identifiants personnels. Personne n’a défini qui devrait y avoir accès, testé la restauration d’une sauvegarde ou documenté sa maintenance. Lorsque l’ordinateur portable est fermé, le processus en arrière-plan s’arrête.
Le code peut fonctionner exactement comme prévu. L’entreprise dépend malgré tout d’un système non géré.
Rien de tout cela ne suppose une intention malveillante ou un outil de programmation incompétent. Chaque étape peut sembler raisonnable lorsque l’objectif immédiat est simplement de créer quelque chose d’utile.
La difficulté consiste à reconnaître le moment où une expérimentation devient un système dont d’autres personnes dépendent.
Le travail au-delà du code
Le développement logiciel comprend une grande quantité de travail à peine visible dans une démonstration réussie :
- Architecture et cohérence. Cette fonctionnalité doit-elle étendre une application existante ? Quelle base de données, quel framework et quels composants partagés doit-elle utiliser ? Comment s’intègre-t-elle aux systèmes et aux conventions d’interface existants de l’entreprise ?
- Intégrité des données. Comment faire évoluer la structure de la base de données sans endommager les enregistrements existants ni interrompre d’autres applications ? Si une requête est réessayée, créera-t-elle un paiement, un ticket ou un client en double ?
- Gestion des changements. Où le code est-il versionné ? Quelle branche contient le changement ? Comment gérer le travail en parallèle, les rebases, les revues, les mises en production et la restauration ?
- Exigences et preuves. Qu’est-ce qui a été demandé et qu’est-ce qui constitue une réussite ? Quelqu’un peut-il suivre une tâche Jira ou un ticket de support à travers l’implémentation, les tests, les preuves et la mise en production ? La clôture du ticket signifie-t-elle réellement que le problème de l’utilisateur a été résolu ?
- Environnements et postes de travail. Quels runtimes, dépendances, conteneurs et services locaux sont approuvés ? Une autre personne peut-elle reproduire la configuration ? Les données et les identifiants de développement, de test, de préproduction et de production sont-ils correctement séparés ?
- Opérations et responsabilités. Qui surveille l’application, contrôle ses coûts, met à jour ses dépendances, répond aux incidents et en assure la maintenance lorsque son créateur passe à autre chose ?
Il faut également prendre des décisions sur l’expérience proposée aux utilisateurs. Deux applications peuvent fonctionner correctement tout en présentant des interfaces contradictoires, en calculant différemment la même métrique métier ou en conservant des versions concurrentes du même dossier client.
Les politiques de l’entreprise s’appliquent tout au long du processus. Une politique d’utilisation de l’IA peut déterminer quels outils et quels comptes sont approuvés. Les exigences en matière de confidentialité influencent les données pouvant être intégrées aux prompts, aux journaux, aux captures d’écran et aux preuves de test. Les règles d’accès déterminent les systèmes qu’une personne — ou un agent agissant pour elle — peut consulter ou modifier.
Ces responsabilités demeurent, même à mesure que la génération de code progresse.
En réalité, nous pouvons avancer cet argument sans débattre de la qualité du code produit par l’IA : même si chaque ligne générée était correcte, ces questions nécessiteraient toujours des réponses.
Donner le contexte à l’IA
Codex et Claude Code peuvent contribuer à une grande partie de ce travail. Un agent peut examiner une architecture existante, préparer une modification de base de données, travailler sur une branche, exécuter des tests, documenter les preuves et mettre à jour une tâche.
Mais il a besoin du contexte de l’entreprise. Une demande telle que « créer un tableau de bord client » n’explique pas, à elle seule, quel système client fait autorité, quels champs sont sensibles ni quelle approbation est requise avant la mise en production.
Il en va de même pour les développeurs expérimentés qui rejoignent une organisation qu’ils ne connaissent pas. Les compétences techniques et la connaissance de l’entreprise sont deux choses différentes. Les deux sont importantes.
La bonne nouvelle, c’est que ces connaissances peuvent être intégrées à l’environnement de développement.
Codex prend en charge les instructions de projet partagées via AGENTS.md. Claude Code prend en charge des consignes persistantes via CLAUDE.md. Les skills, les plugins personnalisés et les intégrations peuvent fournir des workflows réutilisables et un accès aux systèmes où le travail est suivi.
Plutôt que d’expliquer sans cesse comment l’entreprise développe ses logiciels, les équipes peuvent maintenir ces consignes aux côtés du logiciel : quels composants réutiliser, comment tester une modification, où placer les preuves et ce qui doit se produire avant de considérer une tâche comme terminée.
Appuyer les consignes sur des contrôles
Une instruction demandant à un agent d’éviter les données de production doit être soutenue par des identifiants et des autorisations qui restreignent l’accès. Une obligation d’exécuter des tests doit être appuyée par des contrôles de mise en production. Des environnements approuvés doivent permettre de reproduire facilement la configuration attendue.
La documentation de Claude Code distingue explicitement les instructions qui orientent le comportement des autorisations qui contrôlent les actions. Cette distinction est essentielle pour mettre en place un environnement d’entreprise fiable.
Les collaborateurs doivent également comprendre clairement leurs responsabilités. La liberté d’expérimenter peut être large, tandis que l’accès aux informations sensibles et le pouvoir de mettre en production des changements dépendent du rôle de chacun et des conséquences de l’application.
Les ingénieurs expérimentés restent essentiels à ce modèle. Leur jugement façonne l’architecture, établit les contrôles, examine les changements conséquents et transforme les enseignements de projets individuels en fondations réutilisables par d’autres.
Comment Guanta vous accompagne
Chez Guanta, nous aidons les entreprises à construire cet environnement autour du développement assisté par l’IA.
Le travail commence par l’organisation : ses systèmes, ses données, ses politiques, ses équipes et ses responsabilités opérationnelles. À partir de là, nous réunissons des consignes de développement, des composants réutilisables, des intégrations, des environnements contrôlés et des workflows qui relient une demande métier à un résultat vérifiable.
L’objectif est d’intégrer les standards de l’entreprise à la manière dont le travail est effectué, afin que les équipes puissent consacrer davantage de temps à résoudre des problèmes utiles avec l’IA.
C’est ainsi qu’une participation élargie devient durable. Une personne qui a une bonne idée doit pouvoir l’explorer, s’appuyer sur des fondations existantes et suivre un parcours clair vers une solution que l’organisation peut prendre en charge.
La promesse derrière « tout le monde peut coder » mérite de devenir une réalité.
Offrez-leur une cuisine conçue pour cela.