Confier une tâche à l'IA seule : la règle qui évite les mauvaises surprises

La question mal posée avant de confier une tâche à l'IA

Un développeur qui demande « est-ce que je peux laisser l'IA coder ça toute seule » attend presque toujours une réponse basée sur la taille de la tâche. Une fonction isolée, on la laisse filer sans relecture. Une fonctionnalité entière, on met quelqu'un en supervision. Le réflexe est intuitif, il n'est presque jamais discuté en réunion, et il produit régulièrement de mauvaises surprises trois semaines plus tard.

La taille d'une tâche ne dit rien sur son danger. Une fonction de dix lignes peut fragiliser une base de données entière si son entrée n'est pas définie et si personne n'a listé ce qu'elle a le droit de modifier. À l'inverse, une fonctionnalité complète peut être confiée sans supervision constante si le modèle de données, les règles métier et le périmètre ont déjà été posés avant que l'IA n'écrive la première ligne.

Concrètement, une tâche « générer un rapport PDF à partir d'un modèle fixe » est petite et bornée : l'entrée est un objet de données typé, la sortie est un format connu, l'effet de bord est nul en dehors du fichier produit. L'IA peut l'exécuter seule sans risque. À l'inverse, une tâche « améliore le parcours d'inscription » est large et floue : l'entrée n'est pas définie, ni le comportement attendu ni les règles de validation, la sortie n'est jugée que subjectivement, et les effets de bord touchent potentiellement l'authentification, la facturation, les emails transactionnels. La première tâche paraît plus petite dans un board Kanban. Elle est pourtant la plus sûre des deux à confier seule.

Ce que la complexité apparente masque

Un chef de projet regarde une tâche et évalue son ampleur : combien de fichiers, combien d'écrans, combien de jours. Cette évaluation répond à une bonne question, celle du planning. Elle ne répond pas à la question qui détermine si la délégation est sûre : qu'est-ce que l'IA reçoit en entrée, qu'est-ce qu'elle doit produire en sortie, et quels effets peut-elle déclencher en dehors de cette production. Une tâche complexe et bien bornée est plus sûre à déléguer qu'une tâche simple et floue.

Le vrai critère : ce qui est fixé avant que l'IA ne commence

Une tâche est sûre à confier à l'IA seule quand trois éléments sont déjà bornés par un humain : ce qu'elle reçoit en entrée, ce qu'elle doit produire en sortie, et les effets de bord qu'elle peut déclencher au-delà de cette production. Chez Leando, on appelle ça les trois bornes. Le principe est simple à énoncer et systématiquement ignoré sous la pression du planning.

L'entrée bornée signifie que l'IA n'a aucune ambiguïté à interpréter sur ce qu'elle reçoit : un format de données fixé, un contrat d'interface documenté, des cas limites identifiés à l'avance. La sortie bornée signifie qu'un humain sait d'avance à quoi ressemble un résultat correct, et peut le vérifier sans relire chaque ligne de code produite. Les effets de bord bornés signifient que le périmètre d'impact de la tâche est connu : quelles tables, quels modules, quelles autres fonctionnalités peuvent être touchées par ce changement.

Un cadre fonctionnel clair change tout

La différence se voit très concrètement sur le terrain quand on regarde comment les équipes utilisent l'IA. Dans les cas sains, la question posée est étroite : coder cette fonction précise, avec une entrée et une sortie déjà spécifiées, sans autre décision à prendre que l'implémentation elle-même. Dans les cas qui finissent en dette technique, la question posée à l'IA est large : coder toute une fonctionnalité à partir de quelques lignes de spécification, en laissant le modèle décider seul du modèle de données, des cas limites et des dépendances avec le reste du système. Ce n'est pas l'IA qui change entre les deux usages, c'est ce qu'un humain a déjà tranché avant de lui parler.

Ce que le principe exclut

Les trois bornes excluent explicitement un critère : la confiance dans l'outil ou dans la qualité du prompt. Un prompt bien rédigé ne borne rien, il décrit une intention. Ce qui borne une tâche, c'est un travail fait avant, par un humain, sur le modèle de données et les règles métier. Sans ce travail, même le meilleur modèle du marché prend des décisions à la place de quelqu'un, sans que ce quelqu'un le sache.

Ce qui arrive quand la règle est absente

Le scénario se répète avec une régularité inquiétante sur les projets qu'on reprend en urgence. Une équipe, souvent junior, avance vite avec l'IA sur une fonctionnalité entière. Aucune des trois bornes n'a été posée : l'entrée est interprétée au fil des prompts, la sortie n'est validée par personne d'expérimenté, les effets de bord ne sont identifiés qu'au moment où ils cassent quelque chose ailleurs.

Ce qui rend le scénario dangereux, ce n'est pas la vitesse de l'IA en tant que telle, c'est qu'elle répond à toute demande, même floue, sans jamais signaler qu'une décision structurante est en train de se prendre. Un développeur junior qui bute sur une ambiguïté demande normalement à un senior. Un développeur junior qui interroge l'IA reçoit une réponse immédiate, cohérente en apparence, et referme la question sans avoir identifié qu'elle méritait d'être posée à quelqu'un d'autre.

« En 3 semaines, les développeurs juniors avaient globalement pris énormément de décisions techniques sans même les relever auprès de la direction, parce qu'eux-mêmes n'avaient même pas conscience d'avoir pris ces décisions. »

Startup Sportech a vécu une version aggravée du même scénario. Un freelance avait massivement vibe-codé son application avec l'IA, sans borner ni l'entrée ni les effets de bord des fonctionnalités livrées. Le code fonctionnait en démonstration, la mise en production s'est révélée impossible, et un contrat avec Decathlon s'est retrouvé en jeu. Leando a repris le projet en priorisant par impact business plutôt qu'en refaisant l'ensemble du code, et la mise en production a fini par aboutir. Le détail de ce type de dette technique créée en quelques semaines est développé dans l'article sur le vibe coding et la dette technique.

Ce qui arrive quand la règle est appliquée

Chez un fournisseur d'énergie ETI accompagné par Leando depuis fin 2025, une tentative précédente avec des freelances avait sauté cette étape, chacun avançait sur son périmètre sans que les règles métier du secteur soient formalisées nulle part. Le travail de cadrage a consisté à modéliser les objets métier et à formaliser en notation BPMN le processus cible avant la première ligne de code. Une fois ces trois bornes posées, le développement a pu avancer en direct, sans les allers-retours qui existaient avant. L'audit interne du groupe, conduit quelques mois plus tard, a validé la documentation produite pendant cette phase de cadrage.

Les trois bornes ne ralentissent pas le développement, elles déplacent l'effort. Le temps qui aurait été perdu en allers-retours après coup est investi avant, sur la modélisation. Pour aller plus loin sur ce qui distingue un cadrage de projet IA d'un cadrage classique, l'article sur le cadrage projet IA versus classique détaille les quatre spécificités à intégrer.

Appliquer la règle tâche par tâche, pas projet par projet

La règle des trois bornes ne se décide pas une fois pour tout le projet, elle se pose à chaque délégation. Un même projet peut contenir des tâches sûres à confier à l'IA seule et des tâches qui exigent un humain dans la boucle, parfois dans la même journée, parfois dans la même fonctionnalité.

Le test tient en une question posée avant chaque délégation : si vous deviez écrire sur une ligne l'entrée, la sortie attendue et les effets de bord possibles de cette tâche, pourriez-vous le faire sans hésiter ? Si la réponse est oui, l'IA peut agir seule sur ce périmètre précis. Si la réponse est non, la tâche a besoin d'un humain qui pose ces bornes avant, ou qui reste dans la boucle pendant.

Deux tâches, deux réponses différentes

Sur un même sprint, « ajouter un champ optionnel à un formulaire existant, avec validation déjà définie » passe le test sans discussion : entrée connue, sortie vérifiable en un coup d'œil, effet de bord nul en dehors du formulaire. « Refactoriser la gestion des permissions utilisateur » ne le passe pas tant que personne n'a écrit qui a le droit de voir quoi et pourquoi. L'IA peut proposer une implémentation, elle ne peut pas définir les règles d'accès à la place de l'entreprise.

Le bon réflexe avant la prochaine délégation

Avant la prochaine tâche que vous confiez à l'IA sans supervision constante, prenez trente secondes pour écrire ses trois bornes sur une ligne : ce qu'elle reçoit, ce qu'elle doit produire, ce qu'elle peut toucher en dehors. Si vous n'arrivez pas à les écrire, ne la laissez pas seule, peu importe si la tâche vous semble petite.