IA en entreprise : 7 conseils pour choisir votre développeur, vu du Vietnam

L’IA écrit maintenant l’essentiel du code. Alors que faut-il attendre d’un développeur, combien le payer, et que se passe-t-il s’il part ? Mes sept conseils de chef de projet basé au Vietnam, avec pour chacun les collègues du secteur qui vont plus loin.

Dossier · octobre 2026 · en lecture libre

Récemment, j’ai rencontré un dirigeant qui avait bien compris que l’IA codait presque tout. Mais face à son prestataire, il ne savait pas sur quel pied danser. Fallait-il négocier une baisse de prix ? Exiger une meilleure qualité ? Et surtout, comment vérifier ce que l’IA produit ?

C’est là que j’ai mesuré le changement. Les critères pour choisir un développeur ou un prestataire informatique ne sont plus ceux d’avant l’IA. En 2026, l’IA sait produire du code de très bonne qualité. Ce qui compte, c’est ce que le développeur fait autour.

Je pilote des équipes de développement au Vietnam pour des entreprises françaises, depuis Đà Nẵng. Ces conseils viennent de mon expérience. Après chacun, je vous indique trois articles de prestataires, d’analystes ou d’avocats qui vont plus loin, y compris quand ils ne sont pas d’accord avec moi. Les citations sont traduites par mes soins.

1. Choisissez un développeur qui dirige l’IA au lieu d’écrire le code

Un développeur a sa place dans une équipe parce qu’il ne fait pas qu’écrire du code. Avant, pour progresser, il fallait apprendre à écrire du code, et du meilleur code chaque année. Aujourd’hui, s’il écrit encore son code lui-même dans votre entreprise, c’est mauvais signe. Donnez-lui des outils d’IA pour qu’elle écrive à sa place.

L’IA ne remplace pas son esprit critique : écrire de bonnes instructions, sécuriser votre infrastructure, relire ce qu’elle a fait. Sur un même problème, elle peut proposer dix, voire cent solutions. Le développeur devient un décideur, le manager de son IA.

Prenez le compte rendu d’une réunion. À partir du même enregistrement, un commercial demandera à l’IA le résumé d’un rendez-vous client. Moi, je lui demanderai le cahier des charges du projet qui démarre. Un développeur, les aspects techniques, pour anticiper l’architecture. Même source, trois résultats. Dans le code, c’est pareil, tous les jours.

Alors demandez-lui de vous montrer, de bout en bout, comment il traite une demande avec l’IA : un ticket, un module. Interrogez-le sur ses critères, comme vous le feriez pour un chef de projet ou un directeur technique. Les grandes entreprises et les prestataires que je lis font le même constat, même si tous les clients ne sont pas encore prêts.

2. L’IA ne divise pas la facture : négociez d’abord la qualité

Si l’IA code, pourquoi payer le même prix ? Beaucoup de clients se posent la question, et je les comprends. Le module qui prenait un mois se fait en une semaine. Le projet promis en six mois sort en un mois. La tentation est de ne payer qu’une semaine, ou qu’un mois.

En gestion de projet, on raisonne avec le triangle des contraintes. Au milieu, la qualité. Autour, trois côtés : le prix, le délai et le périmètre, c’est-à-dire ce que vous demandez. Prenez un module de facturation électronique, un sujet d’actualité en France. Avec l’IA, on réduit fortement le délai, et peut-être le prix. Le périmètre, lui, ne baisse pas. Il peut même grandir, puisqu’on va plus vite et moins cher.

Mon conseil : si vos demandes ne changent pas, négociez le prix ou le délai. Sinon, servez-vous du gain pour exiger plus de qualité et plus de périmètre.

Ne serrez pas trop non plus. En face, votre prestataire paie toujours ses salariés, il doit se former, et ses outils d’IA ne sont pas donnés. Si votre projet ne lui rapporte plus assez, il le refusera et ira vers des clients plus rentables. Et un délai trop court se paie en qualité. Le code de l’IA est souvent très générique. Pour s’en démarquer, il faut du temps : relire, redonner des instructions, et réunir des humains qui décident d’aller au-delà du premier résultat. C’est là qu’est la vraie valeur de votre équipe.

J’ai vu des sociétés paniquer et proposer à leurs clients des partenariats payés au résultat, au nombre d’abonnements par exemple. Elles s’en mordent les doigts : c’est long à installer, et la relation se complique. Pour moi, le juste milieu reste le jour-homme, avec une part variable liée au résultat : une prime si la qualité monte, une pénalité si elle baisse. Une partie du secteur commence à signer ce genre de contrat.

3. Récupérez le gain de l’IA en fixant les livrables mois par mois

Comment récupérer votre part du gain, alors ? C’est le cœur de ma méthode, celle que j’applique avec mes clients sur la durée : des objectifs fixés chaque mois.

Je ne m’engage plus sur cinq ans, ni même sur un an. Tout change trop vite, et les modèles d’IA qui écrivent le code deviennent chaque mois plus efficaces et plus propres. Chaque mois, vous refaites donc le point avec vos développeurs. Vous partez de ce qu’ils ont livré le mois précédent, et vous fixez ensemble la liste de ce qu’ils livreront le mois suivant.

Puis posez-vous la question : si je paie ce développeur quelques milliers d’euros par mois et qu’il me livre ça, est-ce que mon activité y gagne ? Mes utilisateurs seront-ils mieux servis ? C’est vous le dirigeant, c’est à vous de trancher. Si vous embauchez un chef de projet, demandez-lui d’appliquer cette méthode.

C’est ma façon de partager les économies de l’IA : vous les voyez dans ce qui est livré, pas seulement dans une baisse de coût ou un gain de temps.

4. Exigez qu’un humain nommé réponde de chaque ligne écrite par l’IA

En 2026, s’il y a un bug dans votre logiciel, il y a de fortes chances qu’une IA l’ait écrit. Mais qui en répond ? Vous n’allez pas résilier l’abonnement à ChatGPT.

Ce qui est fondamental, c’est de savoir qui a produit quelle ligne de code. Un assistant ou un agent d’IA doit toujours être rattaché à un humain, et cet humain répond de son agent. Responsabiliser chacun évite la course à l’automatisation irresponsable. Et l’humain garde sa valeur : il dirige l’IA, il garantit la sécurité, et quand la plateforme tombe, il sait d’où vient la panne, quelle ligne l’a causée, à quel moment et pour quel ticket.

Concrètement, exigez deux outils. Git d’abord, le registre qui garde chaque modification du code avec le nom de son auteur et sa date. Puis un outil de gestion des tâches, pour remonter de chaque modification à la demande qui l’a déclenchée et au problème qu’elle devait résoudre. Un bug mal relu n’est pas forcément grave : l’important est d’en retrouver la source.

Ce qu’il faut éviter, c’est le plat de spaghettis : tout marche parce que des IA font tout, et au premier problème, il faut redonner des instructions à l’agent, voire reconfigurer toute la plateforme pendant une journée.

5. Jugez la séniorité d’un développeur à sa connaissance de votre métier

On ne juge plus un développeur expérimenté au nombre de ses années de code. Pour moi, plus il connaît votre secteur, plus il est senior. Il comprend vos demandes, parce qu’il sait d’où elles viennent.

Avec l’IA, tous les secteurs vont évoluer de plus en plus vite. Votre développeur doit suivre votre marché et la façon dont vos clients changent. C’est un nouveau critère, au point que vous pouvez indexer son salaire sur sa connaissance de votre métier. Il vous fera gagner un temps fou pour écrire les spécifications techniques, puis pour relire le code de l’IA, souvent générique ou mal adapté à votre secteur. C’est ce regard critique qu’on attend d’un expert.

L’ancienneté garde tout de même sa valeur. Je ferai toujours plus confiance à quelqu’un qui code depuis quinze ans qu’à un débutant à qui l’on a donné ChatGPT et qui ne sait pas ce qu’est une architecture technique.

6. Exigez une documentation qui survit au départ de votre développeur

Et si ce développeur part demain ? S’il écrit toutes les instructions, contrôle tout et connaît tout de votre métier, votre entreprise risque de perdre son élan. Même en fin de projet : un développeur qui connaît votre métier vous propose sans cesse des améliorations, et vous avez intérêt à le garder au mois.

En 2026, il n’est plus acceptable qu’on vous dise : « Ce bouton, là, demandez à votre robot à quoi il sert. » Exigez une documentation, et une documentation qui parle à tout le monde dans l’entreprise. C’est essentiel pour la durée de vie de votre projet.

Un exemple. Au service client, quelqu’un voit partir un courriel automatique qui l’étonne. Il doit pouvoir ouvrir la liste des modèles de courriels et lire : celui-ci part quand le statut d’une commande n’a pas changé depuis trois jours. Il comprend pourquoi le client l’a reçu, repère peut-être un problème, et fait une demande claire au développeur, qui démêlera le code avec l’IA.

Imaginer que votre développeur peut partir ne veut pas dire que vous voulez vous en séparer. Cela veut dire que c’est à lui de vous montrer comment fonctionne votre plateforme, pour que n’importe qui dans l’entreprise la comprenne.

7. Ce que l’IA ne change pas : pilotage, test court, vérifications

Certaines règles restent vraies avec l’IA. Les clients les oublient au départ, et elles les rattrapent à la fin.

Le pilotage compte plus que le pays. Avec un système qui installe confiance et transparence dans toute l’équipe, vous pouvez travailler avec presque n’importe quel pays, à distance et sur plusieurs fuseaux horaires. J’ai piloté des Macédoniens, des Vietnamiens et des Français, et c’est avec ces méthodes que ça a marché. La bonne question n’est pas seulement combien ça coûte, mais combien d’heures vous gagnez en confiant le travail à un professionnel.

Commencez petit. Je ne le répéterai jamais assez : évitez les énormes cahiers des charges et les longs appels d’offres. Si vous ne pouvez pas réduire le périmètre, confiez dès le premier mois des tâches petites et peu critiques. Si elles sont mal faites, vous ajustez le tir, ou vous arrêtez librement, sans engagement d’un an. Je l’applique aussi à mes propres clients.

Vérifiez les références vous-même. Ne vous fiez pas à la plaquette commerciale. Prenez votre téléphone et appelez les références citées, surtout les projets de votre secteur, comme vous appelleriez l’ancien responsable d’une personne que vous recrutez.

Parlez de sécurité dès le premier jour. Dans les petits projets, personne n’en parle jusqu’au jour où ça casse.

Réparez avant de changer. Si votre prestataire actuel ne coche pas toutes ces cases, ne le remplacez pas au premier virage. Mettez cartes sur table et fixez un calendrier pour corriger ce qui ne va pas. Changer de prestataire coûte énormément d’argent, comme changer de salarié, et surtout beaucoup de votre temps.

Les 7 questions à poser à votre développeur

Ces sept conseils tiennent en sept questions, à poser avant de signer comme à l’équipe déjà en place. Cliquez sur l’image pour l’agrandir, ou enregistrez-la sur votre téléphone.

Checklist : 7 questions à poser à votre développeur ou à votre prestataire en 2026

Quel nom pour ces nouvelles équipes ?

Un dernier changement, plus général. De plus en plus, on réunit un développeur expérimenté et un chef de projet, ou deux débutants et un expérimenté. Ce sont de toutes petites équipes qui avancent en éclaireurs. Un seul développeur avec dix agents d’IA bien configurés peut faire des miracles, là où il fallait dix spécialistes. C’est la nouvelle équipe tech de 2026.

J’ai vu passer le terme « AI Pods », mais je ne veux pas du mot IA dedans : ce sont des humains qui se servent de l’IA. Je cherche un nom. Si vous avez une idée, laissez-la en commentaire.

À propos de Scale in Peace

Je suis Nicolas Thành, chef de projet franco-vietnamien. J’aide les fondateurs français à piloter leur équipe tech au Vietnam : visibilité, livraisons dans le scope, sans réunion inutile.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *