Avec l’IA, les projets sortent des cartons

Premier volet d’une série de trois articles sur les possibilités de réalisation ouvertes par l’IA et les responsabilités qu’elles engagent.

Dans une petite entreprise, une responsable de projets conserve depuis longtemps les croquis d’un outil de préparation des interventions. Elle connaît les informations à réunir, les oublis fréquents et les vérifications à effectuer avant un départ. Le besoin revient à chaque réunion. Le projet, lui, attend : d’autres priorités passent devant, et personne ne dispose du temps nécessaire pour le développer. Cet exemple est fictif. Il décrit une situation possible, sans rapporter un témoignage ni un résultat d’entreprise.

Un assistant d’IA lui permet de reprendre le dossier. Elle décrit les étapes, montre des données inventées pour l’essai, demande une première interface. Quelque chose apparaît à l’écran. Elle peut cliquer, constater ce qui manque, préciser son idée. Le projet change de statut : il devient une proposition que l’on peut examiner.

Cette possibilité mérite l’attention des dirigeants. Certains besoins restent sans réponse parce que leur réalisation paraît trop éloignée des ressources disponibles. L’IA rapproche l’intention d’un premier objet de travail. Reste à déterminer ce que cet objet vaut, pour qui et dans quelles conditions il peut servir.

La réalisation devient plus accessible, pas automatique

L’aide peut porter sur bien davantage que l’écriture du code. Un assistant contribue à clarifier une demande, comparer des façons de faire, représenter un parcours, expliquer une erreur ou préparer une série d’essais. La personne qui connaît le métier dispose ainsi d’un interlocuteur pour transformer une idée imprécise en étapes discutables. Elle peut apprendre en construisant, à condition de rester active dans cette discussion.

La prépublication AI-Assisted End-User Coding, mise en ligne en décembre 2025, apporte un indice limité mais intéressant. Parmi 33 réponses exploitables d’étudiants en génie industriel dans une université allemande de sciences appliquées, 24 déclarent avoir réussi à réaliser un formulaire fonctionnel avec l’aide de l’IA. Le travail relie une interface à Google Sheets. Il s’agit d’un exercice universitaire et de déclarations des participants, sans groupe témoin : aucune validation de produit complet, de sécurité ou de maintenance dans la durée n’en découle.

Cette ouverture concerne des tâches précises : mettre en forme des données, préparer un document, organiser une petite collecte d’informations. Elle ne signifie pas que tout projet devient raisonnable à mener seul. Plus les données sont sensibles, les connexions nombreuses ou les conséquences lourdes, plus l’évaluation technique et métier compte dans la décision.

Il faut aussi lever un malentendu : un logiciel créé avec l’aide de l’IA ne nécessite pas forcément une IA pour fonctionner. Un calculateur ou un formulaire peut être un programme classique. L’assistant intervient pendant sa conception ; le logiciel livré n’appelle aucun modèle génératif si son fonctionnement n’en prévoit pas. Les dépendances réelles doivent être examinées projet par projet.

Entre une interface convaincante et un outil sur lequel compter

Quatre niveaux permettent d’éviter les conclusions hâtives. Un résultat visible montre une interface ou une sortie. Un prototype permet d’explorer une hypothèse dans un périmètre limité, éventuellement avec des données fictives et des fonctions incomplètes. Un outil utilisable rend un service défini, sur des cas vérifiés, avec des limites connues. Un fonctionnement durable suppose en plus que les accès, les sauvegardes, les mises à jour et la reprise puissent être assurés.

Dans notre exemple fictif, afficher une fiche d’intervention est un premier résultat. Vérifier qu’un champ obligatoire manque, qu’un doublon est repéré et qu’une modification ne détruit pas une information en est un autre. Pouvoir récupérer les données après une mauvaise manipulation change encore le niveau de confiance. Une démonstration réussie ne répond pas à toutes ces questions.

Le terme vibe coding entretient parfois la confusion. Dans son sens restreint, retenu ici, il désigne une pratique où l’on guide la génération par les résultats visibles, sans examiner réellement le code produit. Elle peut servir à explorer une idée ; elle laisse une part importante du fonctionnement hors de sa compréhension. Le développement assisté par l’IA couvre aussi des pratiques de lecture du code, de tests, de revue et de contrôle professionnel. Utiliser l’IA ne suffit donc pas à caractériser le degré de maîtrise d’un projet.

Les travaux sur la productivité n’apportent pas non plus une réponse universelle. Dans trois expériences de terrain publiées en ligne dans Management Science le 27 février 2026, Cui et ses coauteurs étudient 4 867 développeurs chez Microsoft, Accenture et une entreprise du Fortune 100 non nommée. Leur analyse combinée estime une hausse de 26,08 % des tâches terminées pour les développeurs disposant de l’assistant de complétion. Les résultats varient entre les expériences ; ce sont des professionnels et un indicateur de production, pas une mesure de réussite pour des débutants créant seuls un outil.

À une autre échelle, METR rapporte le 10 juillet 2025 un temps de réalisation supérieur de 19 % avec les outils d’IA du début de 2025, pour 16 développeurs expérimentés et 246 tâches sur des dépôts open source qu’ils connaissent bien. Ce résultat décrit ce cadre précis. Dans son actualisation du 24 février 2026, METR explique que la sélection des participants et des tâches rend les nouvelles estimations difficiles à interpréter. Elles ne fournissent pas une mesure robuste des gains actuels.

Ces études portent sur des populations, des outils et des mesures différents. Un nombre de tâches terminées supplémentaires ne se compare pas directement à une variation du temps nécessaire pour les réaliser. Aucune de ces observations ne promet une réduction systématique du coût complet d’un projet.

Le travail décisif consiste à préciser, essayer et comprendre

La responsable de notre exemple demande d’abord une fiche « simple et pratique ». Cette formulation laisse ouvertes les règles qui comptent. Qui peut modifier une intervention ? Que faut-il conserver après son annulation ? Comment distinguer une information absente d’une information inconnue ? Une interface soignée peut masquer ces questions jusqu’au premier cas embarrassant.

L’apprentissage consiste à rendre ces règles explicites, puis à confronter le résultat à des situations concrètes. Les travaux de Lucchetti et ses coauteurs, présentés à NAACL en 2025, analysent 1 749 instructions rédigées par 80 étudiants ayant suivi un cours de programmation. Sur ces exercices limités, l’information fournie au modèle explique mieux les difficultés que le seul vocabulaire technique. Reformuler superficiellement ne compense pas une règle manquante. Cette observation ne valide pas une méthode complète de conduite de projet, mais elle éclaire une difficulté très pratique.

On peut commencer par écrire quelques exemples dont on connaît le résultat attendu. Pour chaque modification, on vérifie le cas habituel et un cas qui résiste : une donnée vide, un doublon, un fichier mal formé. On conserve une version qui fonctionne avant de demander la suivante. Lorsque l’assistant propose une correction, on cherche ce qu’elle change et ce qu’elle pourrait casser ailleurs. Demander une explication est utile ; la confronter au comportement observé reste indispensable.

Ce temps de compréhension fait partie du projet. Il peut demander une formation, une aide ponctuelle ou l’abandon d’une approche trop complexe. La pratique personnelle de l’IA par le dirigeant prend ici un sens précis : apprendre assez pour formuler le besoin, apprécier une démonstration et reconnaître le moment où un autre regard devient nécessaire.

L’objection de l’outil fragile mérite une vraie réponse

« Et si personne ne sait le maintenir ? » La question est légitime. Un outil utile peut devenir une difficulté lorsqu’il dépend d’un compte personnel, d’une conversation introuvable ou d’un assemblage que son créateur ne sait plus expliquer. La facilité du premier essai peut reporter l’effort sur les personnes qui devront ensuite résoudre les incidents.

La réponse tient au périmètre accepté. Pour une aide ponctuelle à la mise en forme de données d’essai, on peut décider de refaire le traitement manuellement en cas d’échec. Pour un outil qui conditionne une intervention, un paiement ou une décision engageante, cette solution de secours devient insuffisante. Il faut faire examiner la conception, les droits d’accès, les protections et les cas d’erreur avant de s’y fier. Les exigences suivent les conséquences d’une erreur.

Les professionnels interviennent utilement dès le cadrage : faut-il vraiment développer, adapter un outil existant ou simplement changer une procédure ? Ils peuvent ensuite examiner le code, les échanges de données et les dépendances, puis consolider ce qui mérite d’être conservé. Leur rôle comprend aussi la transmission : ce que quelqu’un d’autre doit comprendre pour reprendre le projet. Cette contribution peut être ciblée sans devenir facultative lorsque les risques l’exigent.

L’hébergement, les abonnements, les corrections et l’accompagnement entrent dans l’effort total. Une solution moins chère à démarrer peut coûter davantage à exploiter. La capacité à exporter les données, retrouver les sources et revenir au fonctionnement précédent mérite donc d’être prévue dès le premier essai. Ce point rejoint les risques décrits dans notre analyse de la dette IA des PME.

Choisir un premier projet dont on peut juger le résultat

Un bon premier projet répond à un besoin précis, fréquent et connu de la personne qui l’évalue. Il accepte un périmètre réduit et des données d’essai. Son résultat peut être contrôlé autrement qu’en demandant à l’IA s’il est correct. Surtout, une erreur reste visible et réversible : le projet n’engage pas silencieusement l’entreprise ou ses clients.

Pour notre outil fictif, un premier essai peut se limiter à préparer une fiche à partir d’informations inventées, sans connexion au système de l’entreprise et sans envoi automatique. Avant de construire davantage, la responsable peut utiliser cette grille de décision. Elle constitue une proposition de méthode, pas un protocole scientifiquement validé.

Question à trancher	Preuve à rechercher pendant l’essai	Décision possible
Le besoin est-il mieux servi ?	Comparer une fiche produite avec la méthode habituelle et repérer les oublis	Conserver seulement les fonctions utiles
Le résultat est-il juste ?	Éprouver des cas dont on connaît la réponse, y compris les erreurs	Corriger avant d’élargir l’usage
Peut-on comprendre et reprendre ?	Retrouver les sources, les règles et une version qui fonctionne	Faire examiner ou simplifier
L’effort reste-t-il raisonnable ?	Compter aussi les vérifications, reprises et frais récurrents	Continuer, réduire ou arrêter
Une panne laisse-t-elle une issue ?	Tester l’export et le retour à la procédure précédente	Préparer le secours avant toute dépendance

Cette évaluation peut aboutir à un outil modeste, à une demande mieux définie pour un prestataire ou à la décision de ne pas poursuivre. Ces issues ont une valeur : elles remplacent une intuition par des éléments que l’on peut discuter. Le premier objectif est de savoir si le projet mérite de continuer, avec quelles compétences et quelles limites.

L’IA remet ainsi certains projets à portée de travail. Elle donne une prise sur une idée que l’on ne savait pas encore concrétiser. Saisir cette possibilité demande du temps, des essais et la volonté de faire vérifier ce qui dépasse ses compétences. Le carton s’ouvre ; la responsabilité de ce que l’on en sort demeure.

Le deuxième volet posera la question : « Des logiciels qui épousent nos façons de travailler : jusqu’où personnaliser ? » Il abordera la personnalisation, la standardisation, la pérennité et le travail collectif. Le troisième portera sur les finalités, l’usage du temps gagné et le partage des bénéfices.

Charger le lecteur Spotify

Ouvrir ce lecteur autorise une connexion à Spotify, qui peut recevoir des informations de navigation.