Aujourd’hui, tout le monde jure par l’IA. Chacun ouvre Claude, Codex ou Cursor, décrit ce qu’il veut, et voit apparaître une application qui tourne. Tout le monde se sent développeur. Moi le premier : je pilote des projets informatiques depuis quinze ans sans avoir jamais été développeur, et je fais aujourd’hui écrire du code tous les jours par un assistant IA.
Ce n’est pas un problème, c’est une très bonne nouvelle. Mais ça pose une question que l’euphorie fait oublier : une application qui tourne sur votre écran n’est pas un produit qu’on met entre les mains de clients. Entre les deux, il y a deux choses que l’IA ne fait pas à votre place : penser l’architecture et tenir la sécurité. C’est exactement là que notre métier s’est déplacé.
Chaque matin, un nouveau produit « boosté à l’IA »
En Nouvelle-Calédonie comme ailleurs, il ne se passe pas une semaine sans qu’on découvre une nouvelle application, un nouvel outil métier, une nouvelle plateforme montée en quelques jours par un entrepreneur et son assistant IA. Certains vont trouver leur marché. Beaucoup vont s’arrêter.
Ceux qui s’arrêtent ne meurent pas d’un mauvais code. Ils meurent de ce qu’il y a autour : une fonctionnalité ajoutée qui en casse trois autres, une base de données qui ne suit plus, une faille qui expose les données des clients, un projet que plus personne ne sait faire évoluer. Ceux qui trouvent leur marché, eux, arrivent tous au même moment : il faut passer à l’échelle, se professionnaliser, et rassurer ceux qui paient.
Ce que l’IA fait très bien, et ce qu’elle ne fait pas
Un assistant IA écrit du code vite, et du code correct la plupart du temps. Il ne se fatigue pas, il connaît tous les langages, il ne fait pas de faute de frappe. Pour sortir un prototype, tester une idée ou automatiser une tâche, c’est imbattable.
En revanche, il fait ce que vous lui demandez, pas ce dont votre projet a besoin. Il ne vous dira pas que la fonctionnalité que vous ajoutez aujourd’hui rendra impossible celle de dans six mois. Il ne garde pas en tête l’ensemble du projet sur trois ans. Et il ne porte aucune responsabilité quand les données de vos clients se retrouvent exposées. Le vrai risque n’est pas que l’IA se trompe : c’est que personne ne relise avant que ça parte en production.
Le métier de développeur n’a pas disparu, il s’est déplacé
On écrit moins de code qu’avant. On passe beaucoup plus de temps sur les deux moments où l’IA ne remplace personne.
Au départ : l’architecture
Avant la première ligne, il y a des décisions qui engagent tout le reste du projet :
- Comment le construire. Quelle technologie, quel hébergement, quelle organisation du code pour que le projet tienne la charge le jour où il marche.
- Ce qu’il doit intégrer. Paiement, comptabilité, outils existants de l’entreprise, connexions avec d’autres logiciels : ce qu’on branche, et comment.
- Comment le faire évoluer sans effet de bord. Qu’une nouvelle fonctionnalité s’ajoute sans casser ce qui marche, et sans tout réécrire à chaque étape.
- Son cœur applicatif. Les règles métier qui font la valeur du produit : elles doivent être isolées, claires et testées, parce que c’est ce que tout le reste va solliciter.
Un projet commencé sans ces décisions coûte plus cher à reprendre qu’à écrire. L’IA produit très vite ; elle produit aussi très vite dans la mauvaise direction.
En continu : la sécurité
Dès qu’un outil stocke des données clients ou encaisse de l’argent, il devient une cible. Et la sécurité ne se règle pas une fois pour toutes. Deux exemples récents : le 21 octobre 2026, deux failles critiques ont été corrigées dans PHP, le langage qui fait tourner une grande partie des sites et outils métier ; les versions trop anciennes n’ont rien reçu. Le 28 octobre, WordPress publiait une version qui corrigeait douze failles d’un coup. Quelqu’un doit appliquer ces correctifs, le soir même, sur votre projet. Si personne n’est nommé, votre projet n’est pas en production : il est en démonstration.
Les garde-fous qu’on met en place, concrètement
Un garde-fou n’est pas un frein. C’est ce qui vous permet de continuer à développer vite, sans risquer de tout casser :
- Un historique du code. Chaque modification est enregistrée et réversible : on peut toujours revenir à la version qui marchait.
- Un environnement de test séparé. Vous essayez ce que vous voulez, vos clients ne voient que ce qui a été validé.
- Une relecture avant chaque mise en production. Rien ne part chez vos clients sans qu’un développeur l’ait relu.
- Les accès et les secrets hors du code. Mots de passe, clés de paiement et accès aux serveurs ne traînent pas dans les fichiers que l’IA manipule.
- Des sauvegardes qu’on a déjà restaurées. Une sauvegarde jamais testée n’est pas une sauvegarde.
- Des données clients sous contrôle. On sait où elles sont, qui y accède, et comment les sortir.
- Un suivi des mises à jour. Les correctifs de sécurité sont appliqués, et on sait ce qui tourne en production, dans quelle version.
Notre positionnement : devenir le CTO de votre assistant IA
Chez One Shot, on ne vous demande plus de nous confier tout le développement. On vous propose de garder la main sur votre projet, et de prendre le rôle que l’IA ne tient pas : celui du directeur technique.
En amont de votre projet. On construit l’architecture avec vous avant que vous lanciez votre assistant IA : ce qu’on construit, dans quel ordre, avec quelles fondations. Vous démarrez sur des bases qui tiendront.
Reprise et industrialisation. Vous avez déjà créé quelque chose sous Claude, Codex, Cursor ou un autre outil de « vibe coding » ? On le reprend, on vous dit ce qui tient et ce qui doit être revu, puis on l’industrialise pour le mettre sur le marché : sécurité, performance, hébergement, mise en production.
Vous continuez à développer, on tient les garde-fous. Vous gardez votre assistant IA et votre rythme. On relit ce qui part en production, on surveille la sécurité, on arbitre les choix d’architecture quand le projet grandit.
Prise en main des outils IA. On vous accompagne dans l’utilisation de Claude et des assistants de code, puis dans vos premiers projets logiciels et vos premiers modules, en travaillant sur votre propre projet. Pour démarrer, notre article sur le paramétrage de Claude en entreprise pose les bases, et notre page intelligence artificielle détaille l’accompagnement.
Quatre questions pour savoir où vous en êtes
- Qui relit ce qui part en production ? S’il n’y a personne, ce n’est pas un problème d’outil, c’est un rôle qui manque.
- Qui applique le correctif de sécurité le soir où il sort ? Nommez la personne.
- Pouvez-vous ajouter une fonctionnalité sans craindre d’en casser une autre ? Si la réponse est non, c’est l’architecture qu’il faut revoir, pas le code.
- Savez-vous où sont les données de vos clients, et comment les sortir ? Si la réponse n’est pas immédiate, c’est le premier chantier.
La conclusion, directe comme on aime
L’IA a mis le développement à la portée de tous, et c’est tant mieux. Mais un produit qui dure a toujours besoin de quelqu’un qui pense son architecture au départ et qui tient sa sécurité ensuite. Ce rôle-là n’a pas disparu : c’est désormais le nôtre.
Si vous avez un projet en tête, une application créée avec l’IA qui commence à trouver ses utilisateurs, ou un outil qui marche sans que personne ne le surveille : parlons-en.