Développer avec l'IA sans perdre le contrôle : Claude, Mistral et moi

Et si l’IA n’était ni un remplaçant, ni un simple assistant ?

Cet article n’est pas vraiment sur WordPress. Ni même sur un plugin de sécurité. C’est un retour d’expérience sur une question qui obsède tous les développeurs : comment collaborer efficacement avec l’IA sans devenir un simple subalterne qui copie-colle le code généré ?

Mon laboratoire : La refonte d’un plugin WordPress utilisé sur plus de 6000 sites.

Mes partenaires IA : Claude (Anthropic)↗ et Mistral AI↗.

Mon rôle : chef d’orchestre, valideur, décideur final.

Le résultat :

1 heure de développement au lieu de 10 à 15 heures
code conforme aux standards WordPress à 100%
zéro régression sur les sites existants
détection de bugs que j’aurais pu manquer seul

Le secret ? Pas l’IA. Pas l’humain. La méthode de collaboration.

Ce que vous allez découvrir :

comment utiliser deux IA en validation croisée
pourquoi Mistral a proposé du code buggé (et comment Claude l’a détecté)
le workflow human-in-the-loop qui change tout
les 40 erreurs que l’IA a corrigées en une passe
ce que seul l’humain peut (et doit) faire

Spoiler : Le plugin WordPress n’est qu’un prétexte. La vraie histoire, c’est comment orchestrer plusieurs IA pour multiplier sa productivité par 20 sans sacrifier la qualité.

Prêt ? Plongeons dans cette collaboration humain-machine. Mais avant, je voudrais rappeler que…

Ce n’est pas ma première expérience avec l’IA

Avant ce projet, j’avais déjà exploré la collaboration IA-développeur :

Première expérience : Générer une application complète avec Gemini CLI

découverte de l’approche CLI/terminal
test de Gemini pour la génération automatisée
premières intuitions sur le workflow

Deuxième expérience : Coder un plugin WordPress avec l’IA

développement plus ciblé sur WordPress
apprentissage des limites spécifiques
compréhension de la validation nécessaire

Cette troisième expérience apporte quelque chose de nouveau : la validation croisée.

C’est la première fois que j’utilise deux IA différentes pour se valider mutuellement. Et c’est ce qui a tout changé.

Le prétexte : un plugin WordPress en production

Stop XML-RPC Attacks↗ : Un plugin WordPress minimaliste, actif sur plus de 6000 sites, conçu pour bloquer les attaques via XML-RPC tout en préservant la compatibilité avec Jetpack et WooCommerce, développé il y a 6 ans déjà pour contrer les attaques de type DDoS sur mon blog.

Pendant des années, la version 1.0.1 a parfaitement rempli son rôle avec une approche minimaliste : moins de 20 lignes de code, zéro configuration, efficace dès l’activation.

1
add_filter('xmlrpc_methods', function ($methods) {
2
unset($methods['system.multicall']);
3
unset($methods['system.listMethods']);
4
unset($methods['system.getCapabilities']);
5
unset($methods['pingback.extensions.getPingbacks']);
6
unset($methods['pingback.ping']);
7
return $methods;
8
});
9
add_action('wp', function () {
10
header_remove('X-Pingback');
11
}, 9999);

12 lignes de code. Zéro configuration. + de 6000 installations actives.

Mais. Parce qu’il y a toujours un mais. Le plugin était efficace mais rigide. Pas d’options, pas de souplesse, pas de logs. Une solution “one-size-fits-all” qui ne convenait probablement pas à tous.

Le défi était de faire évoluer cette solution éprouvée sans casser ce qui fonctionne, tout en apportant la flexibilité nécessaire. En utilisant l’IA pour accélérer ce développement. Mais ce n’était pas au programme…

Acte 1 : Mistral analyse (sans qu’on lui demande)

Un jour, pour montrer qu’on peut résoudre simplement un problème, j’ai présenté mon plugin à Mistral Le Chat :

Mon message (sans rien demander) :

J’ai développé un plugin WordPress pour moi - fonctionalité : bloquer les attaques via XML RPC tout en permettant l’utilisation de Jetpack par exemple - actif sur + de 6000 sites (stats WP) - actif dès l’activation, script de 12 lignes, zéro réglages [Code de la v1.0.1]

Je n’avais rien demandé. Juste présenté mon code.

La réponse de Mistral : une analyse complète non sollicitée

Mistral m’a répondu avec une analyse technique approfondie que je n’avais pas demandée :

Voici une analyse technique et stratégique de votre plugin, ainsi que des améliorations possibles pour le rendre encore plus robuste, tout en gardant sa simplicité.

Points forts identifiés par Mistral :

la simplicité et efficacité du code
le ciblage précis des méthodes dangereuses
la compatibilité Jetpack/WooCommerce préservée
la performance optimale (pas de requêtes DB)

Limites détectées par Mistral :

une approche « liste noire » vs « liste blanche »
une en-tête X-Pingback peut être réajouté par certains thèmes
aucun log des tentatives d’attaque
une compatibilité avec les plugins de cache incertaine

Et surtout : Mistral m’a proposé une version “optimisée” complète, avec :

une architecture orientée objet avec singleton
une interface d’administration avec dashboard
trois modes de sécurité configurables
un système de logging optionnel
des options pour les utilisateurs avancés

Ma première réaction

“Intéressant… mais est-ce vraiment mieux ?”

Avec 6000 sites en production, je ne pouvais pas simplement copier-coller du code proposé par une IA, aussi convaincant soit-il.

C’est là que commence la vraie histoire : la validation croisée. Une partie de ping-pong à trois - Mistral et Claude face à moi qui renvoyait la balle à l’un ou à l’autre en fonction du contexte.

Acte 2 : Claude détecte ce que Mistral a manqué

Face à cette proposition intéressante mais non sollicitée, j’ai eu un réflexe de développeur prudent : demander un second avis. J’ai pris le code proposé par Mistral et l’ai soumis à Claude (Anthropic) :

Ma question à Claude :

Peux-tu me comparer ces 2 approches pour un plugin WP ? [Code original v1.0.1] vs [Code proposé par Mistral]

Au-dela de l’interface d’administration, je voulais comprendre les différences réelles entre les deux versions, identifier les problèmes éventuels et ne pas céder aux sirènes de fausses bonnes idées qui pourraient, de plus, venir avec leur lot de bugs éventuels.

Et des bugs, il y en avait…

Ce que Claude a immédiatement détecté

Bug critique #1 : conflits de filtres

1
// Ligne 13 : Option pour désactiver XML-RPC
2
add_filter('xmlrpc_enabled', '__return_false');
3
// Ligne 57 : Filtre qui s'exécute TOUJOURS (CONFLIT!)
4
add_filter('xmlrpc_enabled', function ($enabled) {
5
if (!is_user_logged_in()) return false;
6
return $enabled;
7
});

Problème détecté par Claude : les deux filtres se contredisent. Le second rend le premier totalement inutile. L’utilisateur qui choisit “Full Disable” se retrouverait avec un comportement différent de celui attendu.

Mistral n’avait pas repéré ce conflit logique.

Bug critique #2 : logging cassé

1
$blocked = array_diff(array_keys($methods), array_keys($methods));
2
if (!empty($blocked)) {
3
error_log('Blocked methods: ' . implode(', ', $blocked));
4
}

Problème détecté par Claude : array_diff() d’un tableau avec lui-même retourne toujours un tableau vide ! Le logging ne fonctionnera jamais.

Mistral avait proposé cette fonctionnalité… qui ne fonctionnait pas.

Bug critique #3 : dégradation prévisible des performances

1
add_filter('rewrite_rules_array', function ($rules) {
2
foreach ($rules as $rule => $rewrite) {
3
if (strpos($rewrite, 'xmlrpc.php') !== false) {
4
unset($rules[$rule]);
5
}
6
}
7
return $rules;
8
});

Problème détecté par Claude : ce filtre est appelé à chaque requête et parcourt TOUTES les règles de réécriture WordPress. C’est coûteux, inutile, et peut dégrader les performances sur les 6000 sites.

Mistral voulait améliorer la sécurité, mais sans se soucier des performances.

Bug critique #4 : hook dans un hook

1
add_filter('xmlrpc_methods', function ($methods) {
2
if (defined('SXRA_LOG_BLOCKED') && SXRA_LOG_BLOCKED) {
3
add_filter('xmlrpc_call', function ($method) use ($blocked) {
4
// Logging ici
5
});
6
}
7
return $methods;
8
});

Problème détecté par Claude : ajouter un filtre à l’intérieur d’un autre filtre crée des hooks en cascade et des comportements imprévisibles. WordPress n’est pas conçu pour ça.

Le constat : Mistral avait raison sur le fond, tort sur la forme

Ce que Mistral a bien fait :

identifier le besoin de flexibilité
proposer une architecture moderne
suggérer des fonctionnalités pertinentes
apporter une vision stratégique correcte

Ce que Mistral a manqué :

des bugs d’implémentation critiques
des conflits logiques dans le code
les standards WordPress n’étaient pas respectés
l’impact sur les performances n’avait pas été anticipé

Ce que Claude a apporté :

une détection précise des bugs
la compréhension globale des standards WordPress
des solutions d’implémentation correctes
des explications pédagogiques pour chaque problème

Acte 3 : L’humain orchestre et décide

À partir de là, le développement est devenu un véritable ping-pong entre les deux IA et moi :

Le workflow en action

Les itérations successives

Itération 1 : Architecture POO corrigée

suppression des bugs de filtres
singleton implémenté correctement
structure de classe propre

Itération 2 : Optimisation des hooks

suppression du filtre rewrite_rules_array
hooks placés au bon moment du cycle WordPress
performance préservée

Itération 3 : Gestion des options

interface de configuration ajoutée
trois modes de sécurité implémentés
options stockées en base de données

Itération 4 : Interface d’administration

tableau de bord avec statistiques
design responsive et accessible
descriptions claires pour chaque option

Itération 5 : Internationalisation

Toutes les chaînes traduisibles (support multi-langues)
Conformité aux standards i18n WordPress

Mon rôle dans cette orchestration

Ce que je n’ai pas fait :

écrire l’architecture from scratch
implémenter manuellement l’interface d’administration
chercher dans la documentation WordPress pendant des heures
tester différentes combinaisons de hooks et priorités jusquà trouver la bonne combinaison

Ce que j’ai fait (et que seul l’humain peut faire) :

décider quelle proposition de Mistral accepter ou refuser
arbitrer entre les suggestions de Claude et mes contraintes
tester à chaque étape avec WP_DEBUG
comprendre l’impact sur 6000 sites en production
maintenir la philosophie « zéro configuration par défaut »
valider que la complexité ajoutée apporte vraiment de la valeur

L’IA propose. L’humain dispose.

Le moment de vérité : 40 erreurs invisibles

Après plusieurs itérations et des tests locaux tous réussis, il est temps de passer la main à Plugin Check (PCP), l’outil officiel de validation.

Premier essai

❌ 40+ ERREURS ET WARNINGS

Le plugin fonctionne parfaitement en local :

WP_DEBUG : 0 erreur tests fonctionnels : OK compatibilité Jetpack : OK performance : excellente

Mais Plugin Checker ne valide pas (au contraire).

Les erreurs que ni Mistral, ni Claude, ni moi n’avions vues

Erreur #1 : Text Domain incorrect

1
// ❌ Le code généré par les IA - fonctionnel
2
define('SXRA_TEXT_DOMAIN', 'stop-xmlrpc-attacks');
3
__('Security Mode', SXRA_TEXT_DOMAIN);
4
// ✅ Ce que WordPress.org exige
5
__('Security Mode', 'stop-xmlrpc-attacks');

Raison : le text domain doit être une chaîne littérale, pas une constante. Sinon les outils d’analyse de traduction de WordPress.org ne peuvent pas le détecter.

Ni Mistral ni Claude ne connaissaient cette règle stricte.

Erreur #2 : les échappements manquants

1
// ❌ Dangereux
2
_e('XML-RPC Security', 'stop-xmlrpc-attacks');
3
// ✅ Sécurisé
4
esc_html_e('XML-RPC Security', 'stop-xmlrpc-attacks');

Raison : toutes les sorties doivent être échappées, même celles qui semblent “sûres”. C’est une règle de sécurité stricte.

Les IA avaient utilisé les fonctions “classiques” sans échappement.

Erreur #3 : fonction dépréciée

1
// ❌ Dépréciée depuis WordPress 4.6
2
add_action('plugins_loaded', function() {
3
load_plugin_textdomain('stop-xmlrpc-attacks', ...);
4
});
5
// ✅ Correct (ne rien faire!)
6
// WordPress.org charge automatiquement les traductions

Raison : depuis WordPress 4.6, les traductions sont chargées automatiquement pour les plugins hébergés sur wordpress.org. Appeler load_plugin_textdomain() est devenu inutile et non recommandé.

Erreur #4 : commentaires traducteurs manquants

1
// ❌ Refusé par Plugin Check
2
echo sprintf(__('Always blocked (%d):', 'stop-xmlrpc-attacks'), $count);
3
// ✅ Accepté
4
/* translators: %d: number of blocked methods */
5
echo sprintf(__('Always blocked (%d):', 'stop-xmlrpc-attacks'), $count);

Raison : les traducteurs ont besoin de contexte pour comprendre ce que signifie le placeholder %d. C’est obligatoire pour toute chaîne avec placeholders.

Aucune IA n’avait intégré cette règle.

Erreur #5 : sanitization manquante

1
// ❌ Dangereux
2
$ip = $_SERVER['REMOTE_ADDR'];
3
// ✅ Sécurisé
4
$ip = isset($_SERVER['REMOTE_ADDR'])
5
? sanitize_text_field(wp_unslash($_SERVER['REMOTE_ADDR']))
6
: 'unknown';

Raison : même $_SERVER['REMOTE_ADDR'] doit être sanitizé selon les standards WordPress. C’est contre-intuitif (une IP fournie par le serveur), mais c’est la règle.

Retour à Claude avec le rapport complet

Ma demande à Claude :

Voici les 40 erreurs du Plugin Check. Peux-tu corriger tout ça ?

Claude me propose une version complètement corrigée, avec :

une explication pour chaque erreur
la correction appropriée
le code complet mis à jour

Deuxième essai : essai transformé

✅ 0 ERREUR ✅ 0 WARNING ✅ 100% CONFORME

Impressionnant. Claude a corrigé les 40 problèmes en une seule passe, en comprenant non seulement ce qui était cassé, mais aussi pourquoi et comment WordPress voulait que ce soit fait.

Temps écoulé pour cette correction : moins de 5 minutes avec Claude. Sans IA : probablement 1 à 2 heures de corrections et de tests.

Les leçons de cette collaboration

Comment ma méthode a évolué au fil des expérimentations

Expérience 1 : Automatisation avec Gemini CLI

génération rapide d’applications
workflow automatisé
contrôle limité sur les détails

Expérience 2 : Plugin WordPress avec Gemini CLI, Claude et ChatGPT

plus de contrôle sur le code
adapté au contexte WordPress
validation manuelle extensive nécessaire via les IA

Expérience 3 (celle-ci) : Validation croisée avec deux IA

détection automatique des bugs
qualité supérieure
confiance renforcée
la méthode qui change tout

Leçon 1 : Les IA ont des forces complémentaires

Mistral : le visionnaire stratégique

Ses points forts :

une vision macro excellente
la détection des faiblesses conceptuelles
propose des architectures ambitieuses
identification des besoins utilisateurs

Ses points faibles :

peut proposer du code avec des bugs
ne connaît pas toujours les standards spécifiques
détails d’implémentation parfois incorrects

Mistral est parfait pour du brainstorming, pour l’architecture initiale, pour l’identification des besoins.

Claude : le technicien rigoureux

Ses points forts :

détection de bugs très précise
connaissance approfondie des standards
explications pédagogiques détaillées
code production-ready
corrections en une passe

Ses points faibles :

parfois plus conservateur
peut manquer de vision “out of the box”

Claude est parfait pour le debugging, la conformité, l’optimisation, la production

Leçon 2 : La validation croisée est indispensable

Ce qui aurait pu mal tourner si j’avais fait confiance aveuglément en l’IA :

Scénario A : Copier-coller du code Mistral

Conséquences potentielles :

bugs dus aux conflits de filtres en production
logging complètement non-fonctionnel
une expérience utilisateur dégradée
impact négatif sur des milliers de sites

Scénario B : Ne consulter qu’une seule IA

Conséquences potentielles :

risque de manquer des optimisations importantes
ou au contraire, sur-optimiser sans raison valable
biais de l’IA non détecté
bugs subtils non repérés

Scénario C : Faire confiance à 100% aux IA

Ce qui s’est réellement passé :

40 erreurs que les IA n’avaient pas anticipées
standards WordPress que les IA ne connaissaient pas tous
code déprécié (load_plugin_textdomain deprecated par exemple )

Leçon 3 : L’humain reste le chef d’orchestre

Ce que les IA ont fait pour moi :

✅ Mistral :

m’a proposé une architecture complète
a identifié les limitations de la v1.0.1
a suggéré des fonctionnalités pertinentes
m’a présenté une vision stratégique du besoin utilisateur

✅ Claude :

a détecté les bugs dans le code Mistral
a corrigé les non-conformités aux standards
m’a expliqué le “pourquoi” de chaque modification
a généré du code production-ready

Ce que seul l’humain peut (et doit) faire :

Décider : Accepter ou refuser chaque proposition
Arbitrer : Entre complexité et simplicité
Comprendre : L’impact sur plus de 6000 utilisateurs
Tester : En conditions réelles, pas juste en théorie
Maintenir : La philosophie du projet (zéro config par défaut)
Assumer : La responsabilité du code déployé

L’IA accélère. L’humain dirige.

Leçon 4 : Les tests automatisés ne suffisent pas

Un rappel important : le code parfait (en théorie) peut être refusé s’il ne suit pas les règles édictées par la plateforme.

Avant Plugin Check :

WP_DEBUG : 0 erreur
tests fonctionnels : Tous OK
compatibilité : Jetpack fonctionne
performance : Excellente

Après Plugin Check :

plus de 40 erreurs de conformité
standards non respectés
règles de sécurité violées
bonnes pratiques ignorées

Pourquoi ? WordPress a des standards très stricts que les tests locaux ne peuvent pas détecter. Même les IA les plus avancées ne connaissent pas toutes ces règles spécifiques.

La leçon : Toujours valider avec les outils officiels, même quand tout fonctionne parfaitement.

Le workflow human-in-the-loop idéal

Voici la méthode qui a émergé de cette expérience :

Étape 1 : Brainstorming avec une IA “visionnaire”

Action : présenter le problème à Mistral (ou similaire)

But : obtenir des idées, une vision macro, des propositions architecturales

Attitude : écouter, noter, mais ne pas implémenter directement

Étape 2 : Validation croisée avec une IA “rigoureuse”

Action : soumettre les propositions à Claude (ou similaire)

But : détecter les bugs, valider l’implémentation, corriger les erreurs

Attitude : cles deux avis, identifier les divergences

Étape 3 : Décision humaine éclairée

Action : choisir ce qui a du sens pour le projet

But : préserver la philosophie, anticiper l’impact utilisateur

Attitude : l’IA propose, l’humain dispose

Étape 4 : Implémentation itérative

Action : développer par petites itérations testables

But : valider à chaque étape, corriger rapidement

Attitude : tests locaux systématiques (WP_DEBUG activé)

Étape 5 : Validation avec outils officiels

Action : Plugin Check, tests de conformité

But : détecter ce que les IA et les tests locaux ont manqué

Attitude : accepter que même l’IA puisse ignorer certaines règles

Étape 6 : Correction finale avec IA

Action : soumettre les erreurs détectées à Claude

But : corriger en une passe si possible tous les problèmes de conformité

Attitude : l’IA excelle dans ce type de tâche répétitive

Étape 7 : Tests en conditions réelles

Action : déployer sur des sites de test variés

But : valider la compatibilité réelle

Attitude : rien ne remplace le monde réel

Les chiffres de cette collaboration

Métrique	Valeur
Version initiale	v1.0.1 (12 lignes de code)
Version finale	v2.0.0 (375 lignes de code)
Message initial à Mistral	1 (présentation, pas de demande)
Analyse Mistral	Complète et détaillée (non sollicitée)
Échanges avec Claude	~20 allers-retours
Bugs détectés par Claude	4 bugs critiques dans le code Mistral
Versions intermédiaires	5 itérations
Erreurs Plugin Check	de 40 à 0 en 1 passe
Tests locaux	8 sites WordPress différents
Temps total de dev	environ 1 heure
Temps estimé sans IA	entre 10 et 15 heures
Gain de temps	~90%
Installations actives	6000+

Le résultat : une solution flexible sans sacrifier la robustesse

Ce qui a changé entre v1.0.1 et v2.0.0

Architecture :

12 lignes → 375 lignes (mais organisées en classe POO)
approche procédurale → architecture orientée objet
code inline → structure maintenable et extensible

Fonctionnalités :

1 mode → 3 modes de sécurité configurables
0 option → interface d’administration complète
pas de logs → logging optionnel avec IP tracking
5 méthodes bloquées → 5 à 8 selon configuration

Expérience utilisateur :

zéro configuration → toujours zéro configuration par défaut
aucune souplesse → 3 niveaux de protection + options avancées
pas de visibilité → tableau de bord avec statistiques en temps réel

Ce qui n’a pas changé

La robustesse :

toujours actif dès l’activation
zéro configuration obligatoire
compatibilité Jetpack / WooCommerce préservée
performance optimale maintenue

La philosophie :

“Ça marche out-of-the-box” reste la priorité
les options sont pour ceux qui veulent plus
la simplicité n’est pas sacrifiée à la flexibilité

L’expérience par défaut :

un utilisateur qui active le plugin ou qui le met à jour sans rien toucher a exactement le même comportement qu’avec la v1.0.1
la complexité est optionnelle, pas imposée

Les trois modes de sécurité

Mode 1 : Full disable (sécurité maximale)

désactive complètement XML-RPC
pour les sites qui n’utilisent ni Jetpack, ni apps mobiles
protection absolue contre toute attaque XML-RPC

Mode 2 : Guest disable (équilibré)

XML-RPC désactivé pour les visiteurs non connectés
autorisé pour les administrateurs authentifiés
bloque les méthodes dangereuses même pour les admins

Mode 3 : Selective blocking (meilleure compatibilité) Par défaut

bloque uniquement les 5 méthodes les plus dangereuses
compatibilité totale avec Jetpack et WooCommerce
le comportement exact de la v1.0.1, mais configurable

L’interface d’administration

Accessible via Réglages → XML-RPC Security :

Tableau de bord visuel avec :

le nombre de méthodes bloquées en temps réel
le mode de sécurité actif
l’état du logging

Options claires :

une description détaillée pour chaque mode
des codes couleur intuitifs (vert = sécurité max, jaune = équilibré)
un avertissement sur l’impact de chaque option

Options avancées :

blocage de l’énumération utilisateur (casse les apps mobiles)
logging des attaques (uniquement si WP_DEBUG actif)

Conclusion : l’IA multiplie les forces, l’humain dirige

Ce projet m’a montré que le futur du développement logiciel n’est ni :

l’IA remplace complètement le développeur
le développeur fait tout manuellement sans assistance

Mais plutôt :

✅ Le développeur orchestre plusieurs IA spécialisées

chaque IA apporte ses forces complémentaires
la validation croisée détecte les faiblesses de chacune
l’humain prend les décisions finales éclairées

✅ Validation systématique et rigoureuse

des tests locaux avec WP_DEBUG
la validation avec des outils officiels (Plugin Check)
des tests en conditions réelles
accepter que même l’IA puisse se tromper

✅ Responsabilité humaine inéliminable

comprendre l’impact sur les utilisateurs
choisir entre propositions contradictoires
maintenir la philosophie du projet
assumer le code en production

Le gain réel : 90% de temps, 100% de qualité

Sans IA : de 10 à 15 heures

recherche d’architecture
implémentation manuelle de l’interface
debugging des problèmes de conformité
lecture de documentation WordPress
développement, tests et debug

Avec IA : environ 1 heure

architecture proposée instantanément par Mistral
bugs détectés en temps réel par Claude
corrections des standards automatiques
explications pédagogiques incluses
conformité validée en 2 passes

La qualité finale est identique, voire supérieure, car :

la validation croisée est plus rigoureuse que celle d’un développeur seul
l’IA a détecté des bugs que j’aurais peut-être manqués
la conformité aux standards est garantie
l’architecture est aussi propre, voire plus propre que ce que j’aurais fait sans IA

Ce que j’ai appris sur moi-même

Cette expérience m’a aussi appris quelque chose sur mon propre processus de développement :

Avant l’IA, j’aurais probablement :

gardé le code minimaliste par flemme d’architecture
évité l’interface admin “parce que c’est long”
ignoré certains besoins utilisateurs par manque de temps

Avec l’IA, j’ai pu :

oser une architecture ambitieuse
créer une vraie interface utilisateur
répondre aux besoins de différents types d’utilisateurs
maintenir un code de qualité professionnelle sans effort surhumain

L’IA ne m’a pas remplacé. Elle m’a rendu meilleur.