Lors de la négociation des prix d’un projet de logiciel sur mesure, les deux parties, A et B, alignent le plus souvent l’unité suivante :« Homme-Ciel »: Combien d’ingénieurs, pendant combien de jours, et à quel prix unitaire. Ce modèle ne fonctionne que lorsque les besoins sont stables et que les périmètres de livraison sont clairs ; dès lors que les règles sur le terrain changent fréquemment, que les outils d’IA augmentent l’efficacité du codage, mais que le client continue d’effectuer la réception selon une logique de « cumul des effectifs », les tensions éclatent — le prestataire estime que les exigences s’étendent, tandis que le client juge que « le nombre de personnes n’a pas diminué, mais le résultat n’a pas été amélioré ».
Signaux politiques : passer de la vente de tête à la vente de résultats
En septembre 2026, le ministère de l’Industrie et des Technologies de l’information a publié le « Plan de mise en œuvre de l’initiative spéciale “Intelligence artificielle + logiciels” », qui mentionne à plusieurs reprises la nécessité de promouvoir la transformation des modèles de production logicielle et de développer les services « Modèle en tant que service » et « Agent intelligent en tant que service », tout en précisant qu’il conviendra d’ici 2028 de créer des applications phares d’agents intelligents dans les secteurs clés. Le document ne rejette pas le développement sur mesure, mais il indique clairement une orientation :Lorsqu’il s’agit d’évaluer la valeur d’un logiciel, on accorde de plus en plus d’importance aux résultats concrets, plutôt qu’à la seule quantité de jours-hommes consacrés.。
Pour les entreprises qui mettent en œuvre des solutions ERP, MES, CRM ou des systèmes de gestion sectorielle, cela signifie que si le contrat ne mentionne encore que « XX personnes × XX jours », il sera très facile, une fois la mise en production, de tomber dans des querelles du type « le code est terminé, mais les processus métiers ne peuvent pas être utilisés ». Une formulation plus durable consiste à décomposer la livraison enRésultats commerciaux acceptables。
Logique métier : les jalons doivent être plus précis que les jours-homme.
Passez le projet de « paiement par étape » à « paiement par jalon » ; chaque jalon doit simultanément satisfaire quatre conditions :
- Scénario d'activité: Qui l’utilise et quelles opérations résout‑il (par exemple « le gestionnaire d’entrepôt scanne le code pour l’entrée en stock » plutôt que « la fonction d’entrée en stock est terminée »).
- Calibre des données: Quelles sont les données principales, les champs d’état et les périmètres de droits d’accès concernés, et quelles sont les règles d’échantillonnage ?
- Script de réception: Avec les données de test fournies, quelles procédures sont exécutées et quels documents ou rapports sont générés.
- Traitement des exceptions: Comment le système s’affiche-t-il en cas d’échec, qui est autorisé à effectuer des modifications et si un journal est conservé.
Les jalons ne doivent pas dépasser2 à 4 semainesUn ; trop long et cela reviendrait au « développement en boîte noire ». Exemple typique de découpage : données principales et autorisations → boucle fermée des documents centraux → rapports et rapprochements → interfaces et passage en production.
Logique de conception : la portée, les modifications et l’« assistance intelligente » sont intégrées au contrat
Le codage assisté par l’IA, la génération automatique de cas de test et la complétion intelligente des documents modifieront la charge de travail humaine nécessaire pour réaliser les mêmes fonctionnalités, maisNe modifie pas automatiquement la complexité des opérations. Dans le contrat et la spécification des besoins, il est recommandé d’établir une section distincte :
- Ligne de base (Baseline): Liste des fonctionnalités + liste des éléments hors scope (Out of Scope), toute modification doit faire l’objet d’un formulaire de changement.
- Modification de la règle de tarification: Les nouveaux jalons sont évalués selon le « scénario + script de validation », et non plus en ajoutant arbitrairement des jours-homme.
- Frontière d’assistance intelligente: Quels processus peuvent être optimisés par l’IA (génération de code, rédaction de documents), et quels doivent obligatoirement faire l’objet d’une signature manuelle (sécurité, conformité, engagements externes) ?
- Attribution de la capitalisation des connaissances: Qui détient les documents de processus, les configurations et les scripts, afin d’éviter une rupture dans la phase d’exploitation après la livraison.
Développement et mise en œuvre : automatisation et observabilité de la phase de validation
Afin de rendre le « orienté résultats » opérationnel, la partie technique doit s’associer à trois actions :
- Inscription des cas d’acceptation dans la base de données: Chaque jalon correspond à un ensemble de cas d’utilisation automatisés ou semi‑automatisés, permettant des exécutions répétitives de la suite de tests.
- Isolement de l’environnement et des données: Les données de l’environnement UAT peuvent être réinitialisées, évitant ainsi le problème « ne fonctionne qu’en environnement de démonstration ».
- Journal observable: Les opérations clés sont enregistrées dans des journaux d’audit, ce qui permet, en cas de litige, de retracer qui a modifié quoi.
Si le projet comprend un agent intelligent ou un moteur de règles, la phase de réception doit être complétée parMécanisme d’échantillonnage aléatoire: Saisissez aléatoirement des cas limites pour vérifier si le refus de réponse, la montée en charge vers un agent humain et le blocage par autorisation sont conformes à la conception, plutôt que de se contenter de s’assurer que « la conversation est possible ».
Trois types de litiges courants et leurs préventions
Controverse n°1 : « Toutes les fonctionnalités ont été développées, pourquoi les services ne les utilisent-ils pas ? »—— Prévention : les jalons sont associés aux opérations de poste et à la validation des formations, avec une vérification sur site lors de la réception, au lieu de se contenter de présenter un PPT.
Controverse n°2 : « Pourquoi faut-il payer davantage pour ajouter une petite fonctionnalité ? »—— Prévention : le bon de modification doit préciser les jalons, les scripts et la durée d’exécution concernés ; le développement ne pourra commencer qu’après la signature des deux parties.
Controverse n°3 : « L’IA a amélioré l’efficacité ; peut-on réduire le nombre de jours humains ? »—— Prévention : le contrat distingue « le coût de réalisation » de « la complexité métier » ; les gains en efficacité peuvent se traduire par une réduction du prix total ou d’une réduction de la durée, mais les critères de réception ne sont pas assouplis.
Proposition de pilote : commencer par un module en boucle fermée
Inutile d’attendre que l’ensemble du système réécrive les contrats. Choisissez-en un.2 à 3 semaines pour boucler la boucledes modules (tels que l’entrée et la sortie des stocks, le signalement du travail par ordre de travail, l’approbation des dépenses), en utilisant un nouveau modèle pour signer des accords complémentaires : lister les scénarios, les scripts, les exceptions et les étapes de paiement. Après avoir validé leur bon fonctionnement, déployer ces solutions à l’ensemble des projets. Pour évaluer le succès, il convient de regarder…Le bon de modification réduit-il le temps consacré aux querelles ?、Le taux de réussite à la première tentative de l’UAT a-t-il augmenté ?, et non pas en regardant combien de jours‑homme ont été sous‑déclarés par la partie B. Si le module pilote est bien choisi, alors la modification du contrat pour l’ensemble du projet sera plus convaincante.
L’humain ne disparaîtra pas du jour au lendemain, mais il est en train de passer d’une « unité de tarification unique » à une « référence pour l’estimation des coûts ». Intégrer les jalons et les scripts de validation dans le contrat constitue la compétence fondamentale permettant aux logiciels sur mesure de continuer à livrer des résultats fiables dans le contexte de l’« intelligence artificielle + logiciel ».
En collaboration avec le prix forfaitaire et les itérations agiles
La validation des jalons n’exclut pas l’agilité : chaque sprint peut toujours livrer un incrément démontrable, maisPaiement et réception officielleAffiché sur une étape majeure plus importante. Dans le cadre d’un contrat à prix forfaitaire, il convient particulièrement de préciser le « point de gel du périmètre » — après quelle réunion d’examen les nouvelles exigences seront traitées par des avenants, afin d’éviter d’ajouter des fonctionnalités oralement. Pour les modules intégrant des agents intelligents, il est recommandé d’organiser une réception d’étape distincte basée sur la « version des règles + taux de réussite des tests d’échantillonnage », sans les lier de manière uniforme au lancement global de l’ensemble du site.
Les données sectorielles indiquent que les projets logiciels échouent à environUn tiersCela provient d’une confusion quant aux critères de besoins et de réception, et non de la mise en œuvre technique elle‑même. Il est plus utile d’inscrire d’abord dans le contrat la définition précise de ce que signifie « être achevé », plutôt que de s’affronter sur le nombre de développeurs remplacés par l’IA. Lors de la prochaine réunion d’évaluation du projet, commencez par poser cette question : si demain toute l’équipe du prestataire était en congé, pourrions‑nous, à l’aide d’un script, déterminer si le jalon actuel est atteint ? Si vous n’arrivez pas à répondre, c’est que les modalités de réception n’ont pas encore été clairement définies. Inclure les jalons dans le contrat n’a pas pour but d’embêter le prestataire, mais de permettre aux deux parties de discuter, sur la même page, de la question suivante : « Est‑ce que c’est fini ? » Cela est d’autant plus important dans les projets où l’efficacité de l’IA est particulièrement manifeste, et il convient de le préciser dès le départ.