En quelques mois, l'IA est passée d'assistant à co-développeur. Elle écrit des fonctionnalités entières, corrige des bugs, propose des architectures. Beaucoup se demandent quels métiers vont survivre. C'est une vraie question, et je ne la prends pas à la légère : certaines tâches, surtout les plus répétitives, vont se réduire.
Mais il y a une question qu'on pose moins souvent, et qui me semble plus importante : quand le code écrit par une IA provoque une fuite de données, qui en répond ?
Une IA ne signe pas
Quand une entreprise subit une attaque, ce n'est pas le modèle d'IA qui s'explique devant les clients, les autorités ou les assureurs. C'est l'entreprise. Ce sont ses dirigeants, ses responsables techniques, ses équipes.
Plus on produit de code vite, plus il y a de code à vérifier. Et plus la question de la confiance devient centrale : ce qui a été livré fait-il ce qu'on croit, et seulement ce qu'on croit ?
Là où l'humain reste indispensable
- Décider de ce qui est acceptable. Quel risque prend-on, pour quel bénéfice ? C'est une décision, pas un calcul.
- Penser comme l'adversaire. Une IA génère ce qu'on lui demande. L'attaquant, lui, cherche ce que personne n'a demandé.
- Vérifier et attester. Tester, prouver, et engager sa signature sur le résultat.
- Expliquer. Traduire un risque technique en décision compréhensible pour un dirigeant.
Ce que ça change pour moi
J'utilise l'IA tous les jours. Ce site a été construit avec elle. Mais je l'utilise comme un collègue très rapide, pas comme un remplaçant du jugement. Les règles, c'est moi qui les écris. La vérification, c'est moi qui la fais. Et la responsabilité, c'est moi qui la porte.
L'IA multiplie la vitesse. Elle ne divise pas la responsabilité.
Si vous dirigez une équipe qui adopte l'IA, posez-vous une seule question : qui, chez nous, vérifie ce qu'elle produit ? Si la réponse n'est pas claire, c'est par là qu'il faut commencer.