Moderniser un logiciel existant pour créer un système intelligent

Scénario illustratif : distributeur, application et changements prévus sont fictifs. Aucun résultat client ni amélioration mesurée n’est présenté.

Partir du changement utile à l’entreprise

Une application de commandes peut rester utile tout en compliquant un nouveau fournisseur, une intégration ou un besoin de reporting. La modernisation relie cet obstacle à un changement utile pour l’entreprise. L’âge du logiciel ne suffit pas à décider de la suite.

Prenons un distributeur fictif dont l’équipe prépare les commandes dans une application existante. Les catalogues fournisseurs décrivent différemment des produits similaires. L’équipe interprète régulièrement les fiches et les rapproche du catalogue interne. Un ancien composant d’import rend cette évolution difficile.

La livraison proposée modernise cette frontière et ajoute un flux intelligent de catalogue. L’IA interprète les fiches fournisseurs convenues et propose des champs normalisés et des correspondances de produits. Les cas courants qui respectent les règles définies peuvent mettre le catalogue à jour automatiquement ; les correspondances incertaines arrivent au responsable. Les décisions de prix et de commande gardent leur périmètre convenu.

Comprendre le comportement réel de l’application

Rassemblez le code autorisé, les versions des dépendances, les instructions de compilation et la configuration de déploiement. Identifiez comment l’import modifie les produits, qui les utilise et quelles interfaces fournisseurs ou licences limitent les changements. Consignez les informations manquantes.

Exécutez la compilation existante dans un environnement de test adapté. Avec une personne connaissant le catalogue, examinez un fichier valide, une ligne mal formée, un produit en double et un import interrompu. Relevez les résultats, avertissements et effets sur les commandes. Convenez du comportement observé à conserver et des défauts existants à corriger.

L’IA peut aider à expliquer du code peu familier, proposer des chemins d’appel et organiser la documentation. Vérifiez ces propositions dans le dépôt, à l’exécution et avec les personnes qui exploitent l’application. Si le point de départ n’est pas reproductible, le rendre reproductible peut constituer la première livraison utile.

Choisir le changement qui lève l’obstacle

Une mise à jour de sécurité traite une exposition précise et demande d’en évaluer l’urgence. Une mise à jour de dépendance change une bibliothèque ou un framework et ses conditions de compatibilité. Un changement de plateforme modifie où ou comment fonctionne l’application. Repenser un processus modifie le travail lui-même. Toutes ces interventions ne sont pas toujours nécessaires.

Pour le distributeur, étudiez si une mise à niveau de bibliothèque prise en charge ou un adaptateur peut offrir une frontière stable à la nouvelle capacité. Préservez le fonctionnement utile des commandes en modifiant le composant retenu. La tâche d’IA exige des entrées et des règles de rapprochement évaluées ; une simple mise à niveau de dépendance ne la livre pas.

La documentation Strangler Fig de Microsoft décrit un remplacement progressif grâce à des limites qui répartissent le travail entre fonctions anciennes et nouvelles. Cela suppose des limites adaptées et des coûts temporaires d’intégration. L’approche doit être évaluée pour l’application concernée. Lecture complémentaire : Microsoft — Strangler Fig pattern

Confier au système le travail courant sur le catalogue

Pour ce flux fictif, convenez des fiches fournisseurs acceptées et des informations internes que le système peut utiliser. L’IA interprète les descriptions, normalise des champs candidats et propose des correspondances. Évaluez des entrées représentatives : noms proches, identifiants manquants et unités contradictoires. Les formats pris en charge et le comportement acceptable font partie du périmètre choisi.

L’application vérifie les champs obligatoires, l’identité du produit, les modifications autorisées et les doublons. Lorsque les contrôles convenus réussissent, elle peut écrire une mise à jour courante autorisée et en consigner le résultat sans approbation individuelle. Une correspondance ambiguë, une modification inattendue ou une écriture échouée rejoint une file d’exceptions avec la source et la proposition. Un score de confiance de l’IA ne suffit pas à autoriser une mise à jour.

Dans cette étape proposée, la fiche produit de l’application reste la référence. Convenez des champs descriptifs modifiables, comme la description normalisée et la référence fournisseur, avant réalisation. Prix, engagements de commande et champs non autorisés sont hors de cette action courante. Évaluez les correspondances sémantiques avec des exemples du catalogue, au-delà du format.

Donnez au responsable une vue des mises à jour terminées, exceptions et actions, avec des moyens de corriger une correspondance ou de suspendre l’automatisation. L’objectif est de rendre le catalogue disponible plus vite avec moins de préparation répétitive, pour réserver les personnes aux décisions importantes sur les produits. Comparez effort, délai de réponse et corrections au processus initial avant de communiquer des gains.

Figure 1 en texte

L’IA interprète les fiches convenues, normalise les champs candidats et rapproche les produits avec le contexte autorisé. Règles de rapprochement évaluées, validation et permissions déterminent les mises à jour descriptives courantes dans la fiche de référence sans approbation individuelle. La confiance du modèle ne suffit pas. Correspondances incertaines ou contradictoires, changements inattendus et écritures échouées arrivent au responsable avec source et historique. Les personnes corrigent les exceptions et peuvent suspendre le flux. Prix et engagements de commande restent hors de ces écritures. Le fonctionnement des commandes existantes reste une dépendance à tester. Nous appliquons l’IA là où elle crée une valeur utile, avec contexte, architecture et vérifications définis. Une voie séparée de la méthode Devmojos présente une IA utile et un contexte défini, une architecture et des actions délimitées, puis des tests, une revue et une évolution maîtrisée.

La méthode Devmojos : contexte, architecture et vérifications visibles

Nous construisons cette capacité avec l’aide de l’IA selon le processus de livraison de Devmojos. Le harness donne aux agents de programmation une tâche définie, le code et les contrats utiles, des exemples représentatifs et des permissions explicites. Les agents proposent modifications, tests et documentation ; les ingénieurs examinent les résultats et décident de l’acceptation de la version. Cette méthode de livraison est distincte de l’IA qui interprète les catalogues en fonctionnement.

Un test généré peut reproduire la même hypothèse erronée que le code généré. Comparez les deux à des exemples et résultats attendus choisis indépendamment. Effectuez les contrôles de dépendances, compatibilité et sécurité adaptés à la technologie. OWASP Dependency-Check recherche par exemple des vulnérabilités connues et publiées dans les dépendances ; cela ne démontre pas la sécurité de toute l’application.

Consignez le travail utile, y compris revue et corrections. Un changement accepté apporte des éléments pour cette application et ce périmètre. Affirmer une livraison plus rapide ou un coût total inférieur nécessite une référence comparable et les coûts pertinents de travail et d’exploitation. Lecture complémentaire : OWASP — Dependency-Check

Tâches claires et contexte réutilisable visent moins de reprises et un chemin plus court vers une livraison utile. Tests et revue indépendante apportent des preuves de qualité ; permissions délimitées et contrôles adaptés soutiennent maîtrise et sécurité. Interfaces modulaires, décisions documentées et tests de charge aident à préparer évolution, développement futur et montée en charge. Comparez coûts de réalisation, revue, modèles et exploitation avant d’affirmer un résultat plus économique. Le logiciel classique traite les étapes qui ne nécessitent pas d’IA.

Livrer une partie complète de l’import

Préparez l’import intelligent dans un environnement de test avec des données représentatives autorisées. Testez extraction des champs et rapprochement des produits séparément de la validation et des écritures. Incluez un cas courant qui avance automatiquement et une correspondance incertaine transmise à une personne. Vérifiez doublons, entrées rejetées et effets sur les commandes.

Convenez du comportement en cas d’interruption. Certains systèmes peuvent finaliser l’import dans une transaction ; d’autres exigent une reprise ou une réconciliation explicite. L’implémentation doit correspondre à l’application et au modèle de données. Définissez les enregistrements de référence et l’identification du travail partiellement traité.

Reliez chaque exemple convenu au résultat réel, y compris correspondances erronées, mises à jour indues, exceptions et corrections de l’opérateur. Vérifiez qu’une personne comprend pourquoi une mise à jour a eu lieu et peut arrêter le flux. Les responsables métier et technique acceptent la capacité retenue à partir de ces preuves.

Préparer la mise en production et la récupération

Répétez les étapes de déploiement. Définissez qui peut suspendre l’import, vérifier les résultats et organiser la continuité du travail si le changement est arrêté. Un déploiement limité peut aider lorsqu’une partie représentative du travail peut être isolée. Choisissez des signaux révélant les défauts du comportement modifié.

La documentation SRE de Google décrit un déploiement canari comme une mise en service partielle, limitée dans le temps et évaluée avant de continuer. Sa pertinence dépend d’un trafic représentatif et de signaux utiles. Un petit échantillon ou une période calme peut masquer un problème important.

Distinguez revenir au code précédent et récupérer les données déjà écrites. Une ancienne version peut ne pas lire un schéma modifié. Restaurer une sauvegarde peut supprimer du travail valide ultérieur. Préparez compatibilité, restauration, retraitement ou actions compensatoires avant de modifier les données de production, puis testez la procédure lorsque c’est possible. Lecture complémentaire : Google SRE — Canarying releases

Figure 2 en texte

Deux décisions liées demandent des éléments distincts. Le code précédent peut-il fonctionner avec les données et le schéma actuels ? Comment récupérer ou réconcilier les enregistrements déjà écrits ? Selon le changement, le plan peut exiger compatibilité, restauration, retraitement ou action compensatoire. Une sauvegarde restaurée peut supprimer du travail valide ultérieur. La procédure est choisie pour l’application et testée lorsque c’est possible. Une voie de livraison séparée montre le contexte de tâche, code et interfaces, les propositions de modifications et tests par IA, puis tests, revue et décision humaine de mise en production. Elle explique la construction de la capacité intelligente, pas une récupération automatique.

Décider de la suite avec la première livraison

Transmettez le composant modifié, la compilation reproductible, les tests et les procédures de mise en production et récupération des données. Ajoutez la vue d’exploitation, les règles d’exception, les dépendances de modèles et d’entrées et l’autorité de suspension ou de reprise. Documentation utile et contrôle direct peuvent réduire le recours au fournisseur pour les ajustements quotidiens ; modèles, logiciels et plateformes gardent leurs responsables.

La suite peut être un autre composant, une mise à jour courante ou le maintien de l’application actuelle. Des accès, responsables d’intégration ou preuves de récupération manquants peuvent arrêter une migration proposée. Un système utile avec un besoin limité peut justifier une intervention bien plus petite qu’une réécriture.

Apporter une application et le changement nécessaire

Pour un premier échange, identifiez l’application, le changement bloqué et les personnes qui l’utilisent et la maintiennent. Précisez les accès au code et à la compilation, les intégrations importantes, contraintes connues et fenêtre de continuité acceptable. Réservez identifiants et données sensibles à un cadre de travail convenu séparément.

Devmojos relie la modernisation progressive à une capacité intelligente utile dans l’application dont dépend déjà votre activité. Une première livraison délimitée et des composants réutilisables visent des coûts accessibles et plus de capacité d’adaptation des produits, processus et services. L’analyse intervient si nécessaire ; un périmètre clair peut être réalisé directement. AI Engineering accompagne votre équipe, et l’exploitation continue fait l’objet d’un accord séparé.