La réécriture de code par l’IA de Cisco place un objectif de 98 % derrière des tokens illimités

Cisco aurait donné à un ingénieur de 27 ans des tokens d’IA illimités pour réécrire 98 % de son code hérité en 24 mois. La réécriture de code par l’IA de Cisco associe un objectif exceptionnellement vaste à une petite équipe proposée. Son importance dépend de ce que Cisco entend modifier et de la manière dont l’entreprise établira que ces changements fonctionnent.

Selon Tom’s Hardware, qui relaie les informations de Fortune, le président et directeur des produits Jeetu Patel a soutenu l’ancien fondateur de startup Padmanabhan Krishnamurthy après une conversation à San Francisco. La mission comprendrait une période de validation initiale de quatre semaines. Ces éléments décrivent une expérimentation et une ambition, plutôt que des résultats de modernisation vérifiés de manière indépendante.

La tension centrale oppose la génération de code sans restriction à la livraison responsable de logiciels. Amazon a déjà décrit des mises à niveau d’applications assistées par l’IA, offrant un point de comparaison utile. L’ambition rapportée de Cisco soulève une question plus large : quelle part de responsabilité organisationnelle une petite équipe d’ingénierie peut-elle assumer lorsque générer des changements devient plus facile ?

La réécriture de code par l’IA de Cisco commence par un objectif, pas par une migration achevée

La mission rapportée établit un soutien de la direction ; elle ne prouve pas que Cisco a modernisé ses logiciels.

Le récit de Tom’s Hardware concernant la mission liée au code hérité identifie Krishnamurthy, connu sous le nom de Paddy, comme l’ingénieur à l’origine de la proposition. Il aurait proposé une équipe de deux personnes. Patel aurait apporté son soutien, y compris des tokens sans restriction, les unités de texte que les modèles d’IA traitent lorsqu’ils reçoivent des instructions et génèrent des réponses.

Le rapport indique que Krishnamurthy travaillait auparavant cinq niveaux hiérarchiques sous Patel. Il présente le projet comme un changement de responsabilité autant que d’outillage. Un ancien fondateur disposerait de la marge nécessaire pour remettre en cause des hypothèses d’ingénierie établies.

Des antécédents d’acquisition vérifiables de manière indépendante étayent ce lien. L’avis d’acquisition d’EzDubs de Cisco indique que la transaction a été finalisée le 25 novembre 2025. Cisco a décrit EzDubs comme une entreprise de logiciels d’IA spécialisée dans la traduction vocale en temps réel. La justification avancée incluait l’élargissement des talents d’ingénierie de la collaboration.

Cet historique confirme le récit d’une startup acquise rejoignant Cisco. Il ne valide pas indépendamment la proposition de réécriture ni sa faisabilité. L’annonce d’acquisition porte sur des capacités de collaboration, plutôt que sur un plan publié visant à transformer les logiciels hérités de Cisco.

La formulation de la mission rapportée exige également de la prudence. Le refactoring consiste à modifier la structure interne d’un logiciel tout en préservant son comportement observable de l’extérieur. La réécriture peut impliquer le remplacement d’une implémentation, et donc potentiellement introduire des choix de conception et des risques de compatibilité différents.

Ces termes peuvent décrire des travaux qui se recoupent, mais ils ne constituent pas des mesures interchangeables de progression. Un nettoyage interne automatisé diffère considérablement du remplacement d’un composant dont dépendent les clients. Un programme de modernisation doit identifier à quelle catégorie appartient chaque changement.

Les informations publiques ne fournissent pas d’inventaire détaillé sous-jacent au chiffre de 98 %. Elles n’expliquent pas non plus si l’achèvement désigne des changements générés, des changements acceptés, un déploiement en production ou le retrait d’anciennes implémentations. Sans ces définitions, le pourcentage communique plus clairement une ambition qu’un périmètre opérationnel.

La même prudence s’applique au calendrier. Des informations publiées le 30 octobre 2026 n’établissent pas que le chronomètre du projet a commencé ce jour-là. Les lecteurs devraient éviter de calculer une date d’achèvement exacte à partir de la seule date de publication.

Le point de départ utile est donc limité. Le président de Cisco aurait autorisé une expérimentation d’ingénierie ambitieuse assortie d’un objectif phare défini. La question de savoir si cette expérimentation deviendra un programme de modernisation reproductible reste distincte.

Les tokens illimités déplacent la pression vers la revue et la responsabilité

Supprimer une limite de génération modifie l’endroit où le travail d’ingénierie s’accumule ; cela n’élimine pas le travail nécessaire pour accepter un changement.

Des tokens d’IA illimités peuvent sembler offrir une capacité d’ingénierie illimitée, car le résultat visible est du code. Pourtant, un correctif généré, c’est-à-dire une modification proposée de fichiers sources, doit toujours avoir une raison d’être. Quelqu’un doit établir ce qu’il modifie, pourquoi il est sûr et qui en assurera la maintenance.

Prenons une modernisation hypothétique d’un composant d’authentification partagé. Un outil d’IA pourrait suggérer un code plus clair, des dépendances plus récentes et des tests supplémentaires. Cette proposition devrait néanmoins être évaluée au regard des règles d’autorisation existantes et des configurations clients prises en charge.

Cet exemple est illustratif, plutôt qu’une description du projet de Cisco. Il montre pourquoi générer un logiciel plausible et accepter la responsabilité du comportement déployé sont des activités différentes. Une rédaction plus rapide peut révéler un manque de relecteurs plutôt qu’éliminer un manque de programmeurs.

Les responsables d’ingénierie subissent une pression immédiate. Si les changements proposés arrivent plus vite que les équipes ne peuvent les évaluer, la file d’attente de revue s’allonge. Les responsables doivent alors décider s’il faut restreindre le travail, accroître la capacité de revue ou modifier la manière dont les preuves accompagnent chaque proposition.

Les spécialistes de la sécurité font face à un problème connexe. Ils doivent comprendre si le processus préserve les frontières d’accès et traite les informations sensibles de manière appropriée. Un correctif qui paraît plus propre peut tout de même modifier des hypothèses auparavant appliquées indirectement.

Les responsables produit doivent distinguer les améliorations internes des changements qui affectent les clients. Le remplacement d’une dépendance, un composant logiciel externe, peut introduire des comportements allant au-delà des fichiers qu’un outil d’IA modifie directement. L’acceptation dépend donc du système environnant, et non simplement de l’attrait du remplacement.

Le soutien de la direction importe parce que ces responsabilités traversent les lignes hiérarchiques. Une petite équipe centrale peut développer une approche, mais les équipes concernées ont toujours besoin d’un moyen d’approuver les changements. Une autorité floue transformerait chaque démonstration réussie en négociation sur la personne qui accepte les conséquences.

C’est là l’importance organisationnelle des ambitions de réécriture de code par l’IA de Cisco. L’expérimentation teste si une petite équipe peut créer un processus auquel les autres équipes font confiance. Ses résultats devraient inclure des preuves reproductibles, des limites de changement compréhensibles et des voies claires pour traiter les défaillances.

Les mainteneurs établis restent au cœur de ce processus. Ils savent souvent pourquoi une implémentation maladroite existe ou quelle exigence client explique une branche inhabituelle. Cette connaissance constitue une preuve utile, même lorsqu’elle indique que l’implémentation actuelle devrait changer.

La documentation devient une partie de la question de la capacité d’ingénierie. Les équipes ont besoin d’accéder aux décisions de conception, aux historiques d’incidents et aux exigences de compatibilité avant d’évaluer un remplacement proposé. Une base de connaissances d’ingénierie consultable répond à ce problème d’information en parallèle du flux de travail de codage.

La pression qui en résulte s’exerce des deux côtés de l’expérimentation. La petite équipe doit rendre son travail révisable, tandis que les équipes établies doivent expliquer concrètement leurs objections. Ni la génération sans restriction ni l’expérience institutionnelle ne fournissent de réponse automatique.

Les mises à niveau d’applications d’Amazon offrent une comparaison plus limitée

Une migration délimitée fournit des preuves plus claires qu’un pourcentage couvrant un patrimoine logiciel indéfini.

Amazon fournit un précédent industriel pour la modernisation assistée par l’IA. Dans son annonce de transformation d’applications de décembre 2024, l’entreprise a décrit la mise à niveau d’applications internes vers Java 17. Java est un langage de programmation et un environnement d’exécution utilisé pour les logiciels d’entreprise.

Amazon a déclaré que l’effort couvrait des dizaines de milliers d’applications de production et avait économisé plus de 4 500 années-développeur de travail. Il s’agit de résultats déclarés par l’entreprise, plutôt que d’une évaluation indépendante. Ils décrivent néanmoins une transformation plus précise qu’une promesse générale de réécrire du code hérité.

Cette précision est importante. Une mise à niveau de version fournit un état initial et un état cible identifiables. Les relecteurs peuvent examiner si une application se compile, si le comportement attendu reste intact et si le nouvel environnement d’exécution prend en charge ses exigences.

Une réécriture plus vaste peut combiner de nombreux objectifs différents. Elle peut consister à simplifier l’architecture, remplacer des dépendances, améliorer la maintenabilité ou supprimer des fonctionnalités obsolètes. Chaque objectif exige ses propres critères d’acceptation, même lorsque les mêmes outils d’IA aident à produire les changements.

Le flux de travail de mise à niveau Java d’AWS préserve également une étape explicite d’acceptation humaine. Sa documentation décrit la compilation du code d’origine, l’exécution d’une transformation, puis la demande au développeur de vérifier et d’accepter les résultats. Elle distingue les changements de compatibilité du langage des mises à niveau supplémentaires de dépendances.

Cette distinction est utile parce que la modernisation est rarement une opération unique. Une mise à niveau réussie du langage ne prouve pas que chaque bibliothèque est à jour. Une compilation réussie ne prouve pas que chaque flux de travail client se comporte correctement.

L’exemple d’Amazon soutient donc une conclusion limitée : la transformation assistée par l’IA possède des applications concrètes en entreprise avec des limites descriptibles. Il ne prouve pas que l’objectif rapporté de Cisco soit réalisable. Il ne montre pas non plus qu’une équipe de mise en œuvre minuscule puisse accomplir de manière indépendante toutes les tâches d’acceptation associées.

Il y a également une leçon de mesure. Le temps de développement estimé comme économisé dépend d’un processus alternatif supposé. Cette estimation devient plus informative lorsqu’elle s’accompagne d’applications déployées, de changements acceptés et de performances opérationnelles continues.

L’expérimentation de Cisco bénéficierait de rapports tout aussi concrets. Une description de la charge de travail initiale révélerait si l’équipe teste une transformation reproductible ou explore une refonte plus large. Les deux peuvent être utiles, mais elles comportent des incertitudes différentes.

Pour les acheteurs d’entreprise, cette distinction affecte la manière d’interpréter les affirmations des fournisseurs. Une démonstration interne est une preuve concernant un processus particulier dans un environnement particulier. Une capacité client prise en charge exige des engagements supplémentaires en matière de maintenance, de documentation et de traitement des défaillances.

La pression concurrentielle concerne autant les preuves que la vitesse. Les entreprises qui parlent de modernisation par l’IA doivent de plus en plus expliquer ce qui a été transformé et comment l’acceptation a fonctionné. Un pourcentage spectaculaire en manchette fournit moins d’informations utiles qu’un résultat clairement délimité.

La comparaison permet également de garder l’histoire de Cisco ancrée dans le réel. Son importance vient de l’évaluation de la capacité d’un soutien exécutif ambitieux à étendre la portée de l’ingénierie assistée par l’IA. L’expérience d’Amazon fournit un contexte sans résoudre cette expérimentation à l’avance.

Le chiffre de 98 % doit être défini avant de devenir une mesure utile

Un pourcentage de modernisation ne devient significatif que lorsque les lecteurs savent ce qui compte dans son calcul.

Un pourcentage nécessite un dénominateur, c’est-à-dire la quantité totale à laquelle les progrès sont rapportés. Pour cette mission, il peut s’agir de lignes de code source, de dépôts, d’applications ou de composants sélectionnés. Le reportage n’établit pas quelle interprétation s’applique.

Ces choix peuvent donner des images très différentes des progrès. Reformater des fichiers peut toucher de nombreuses lignes de code sans améliorer leur maintenabilité. Remplacer un composant modeste mais central peut exiger une validation poussée tout en affectant relativement peu de code.

La règle d’achèvement compte tout autant. Générer une modification proposée constitue une étape intermédiaire. L’accepter dans le dépôt source en est une autre, tandis que son déploiement et le retrait de l’ancienne implémentation exigent un travail supplémentaire.

Cela ne rend pas l’objectif de 98 % intrinsèquement déraisonnable. Cela rend cette ambition difficile à évaluer à partir de la description publique. Les lecteurs ont besoin de définitions de périmètre et d’acceptation avant de l’interpréter comme une prévision d’ingénierie.

Le langage du refactoring crée un autre défi de mesure. La préservation du comportement est au cœur du refactoring, mais les tests existants n’examinent que les comportements qu’ils couvrent. Une exécution réussie des tests ne peut établir que chaque condition non testée demeure inchangée.

Cette lacune explique pourquoi la revue et l’observation en conditions réelles comptent. Une régression, c’est-à-dire une perte involontaire d’un comportement existant, peut apparaître en dehors des scénarios représentés dans les tests automatisés. La confiance provient de la combinaison des preuves plutôt que du traitement d’un contrôle isolé comme conclusif.

La recherche met également en garde contre l’assimilation de l’impression de rapidité à une productivité mesurée. L’expérience de METR sur la productivité des développeurs a étudié 16 développeurs expérimentés réalisant 246 tâches dans des projets open source qu’ils connaissaient bien. L’autorisation d’utiliser des outils d’IA du début de l’année 2025 a augmenté le temps d’achèvement de 19 %.

Les participants pensaient néanmoins que les outils les avaient aidés à terminer plus vite. Ce constat illustre pourquoi la commodité perçue et la vitesse de livraison mesurée nécessitent des évaluations distinctes. Il ne prédit pas les résultats de Cisco et n’établit pas que les outils d’IA plus récents présentent les mêmes limites.

METR a ensuite souligné cette distinction. Sa mise à jour de février 2026 sur la conception de l’expérience décrivait les difficultés d’interprétation de mesures plus récentes, car la participation et la sélection des tâches avaient changé. Les chercheurs jugeaient plausible une amélioration de la rapidité tout en avertissant que les éléments disponibles ne permettaient pas d’établir précisément le gain.

Pris ensemble, ces résultats plaident pour une mesure attentive plutôt que pour un verdict universel sur la programmation assistée par IA. Les capacités des outils évoluent, et des tâches différentes révèlent des contraintes différentes. Les résultats de la maintenance de projets open source familiers ne peuvent pas simplement être transposés à un programme de modernisation d’une grande entreprise.

Pour Cisco, la question pertinente est de savoir si le processus complet s’améliore. Une génération plus rapide aurait une valeur limitée si la revue et la correction absorbaient le temps gagné. À l’inverse, un processus fiable pourrait apporter de la valeur même s’il laissait délibérément une part importante du code intacte.

Une évaluation crédible distinguerait donc l’activité des résultats. Les correctifs proposés montrent une activité ; les transformations acceptées montrent des progrès après revue. Un déploiement stable et une charge de maintenance réduite apportent des preuves plus solides que le travail a atteint son objectif.

Des tokens illimités suppriment une contrainte potentielle sur l’expérimentation. Ils ne résolvent pas ces questions de mesure. L’objectif rapporté devient plus informatif lorsque Cisco explique comment il distinguera une démonstration impressionnante d’une amélioration durable de l’ingénierie.

Une petite équipe a toujours besoin d’accéder aux connaissances institutionnelles

La version la plus solide de cette expérience combine la liberté de repenser avec l’accès aux raisons pour lesquelles les logiciels existants se comportent comme ils le font.

L’histoire du recrutement invite à une interprétation générationnelle simple. Un jeune fondateur remet en cause des hypothèses qu’une grande organisation a acceptées. Ce cadrage reflète le changement d’opportunité rapporté, mais il ne peut établir quels jugements d’ingénierie sont corrects.

La jeunesse ne produit pas automatiquement une architecture saine, tout comme l’ancienneté ne justifie pas automatiquement la préservation d’une implémentation. La distinction utile est de savoir si une proposition résiste à l’examen. Une petite équipe a besoin d’assez de liberté pour tester des idées et d’assez de contexte pour interpréter les résultats.

Le parcours de fondateur de Krishnamurthy, tel qu’il est rapporté, est pertinent pour cette question organisationnelle. L’expérience en startup peut encourager l’attention portée à l’ensemble du problème plutôt qu’à une tâche étroitement assignée. Elle ne remplace toutefois pas la compréhension des systèmes affectés par une modification.

Les connaissances institutionnelles peuvent expliquer des inefficacités apparentes. Une séquence de tentatives inhabituelle peut tenir compte d’une condition d’exploitation particulière. Une vérification redondante peut protéger une intégration plus ancienne. Il s’agit d’exemples hypothétiques, et non de fonctionnalités identifiées du logiciel de Cisco.

Ces explications devraient devenir des exigences testables chaque fois que possible. Sinon, la modernisation dépend de l’identification de la personne qui se souvient d’une ancienne décision. Documenter la raison permet à une nouvelle implémentation de préserver le comportement nécessaire tout en remettant en cause la conception d’origine.

L’obligation inverse compte également. Les équipes établies devraient distinguer les exigences documentées des habitudes qui ont survécu sans examen. Une objection devient exploitable lorsqu’elle identifie une condition d’échec ou un critère d’acceptation.

C’est là que le soutien de la direction peut aider sans remplacer le jugement d’ingénierie. La direction peut autoriser l’accès, résoudre les litiges de propriété et protéger le temps consacré à l’évaluation. Elle ne peut pas établir la justesse par l’enthousiasme ni faire d’une échéance un substitut à la preuve.

La contribution la plus précieuse d’une petite équipe pourrait donc être un processus reproductible plutôt qu’une grande quantité de code de remplacement. Ce processus relierait les transformations proposées aux exigences pertinentes et à un parcours d’approbation clair. D’autres équipes pourraient alors évaluer des travaux similaires sans devoir reconstruire la procédure.

Cette possibilité modifie l’interprétation du niveau de recrutement proposé. Une équipe compacte pourrait élaborer des méthodes de transformation et coordonner leur adoption. Cela diffère de l’affirmation selon laquelle ces personnes pourraient, à elles seules, assumer toutes les responsabilités de test, de sécurité, de support et de maintenance.

Elle limite également ce que cette histoire dit de l’emploi de début de carrière. Confier à un fondateur acquis une responsabilité inhabituelle n’établit pas une tendance générale de recrutement. Ce cas apporte des éléments sur une décision managériale particulière, plutôt que sur un résultat du marché du travail.

Pour les développeurs, l’implication pratique concerne le travail qui entoure le code généré. Comprendre les exigences, expliquer les compromis et établir des preuves restent nécessaires lorsque la rédaction devient plus facile. Ces responsabilités deviennent plus visibles lorsqu’un projet tente des changements au-delà des frontières organisationnelles.

Pour les travailleurs du savoir plus largement, le parallèle réside dans l’accès au contexte. Un système d’IA peut produire une réponse plausible tout en ignorant la raison pour laquelle une décision antérieure comptait. Une automatisation utile a besoin d’un moyen de retrouver cette raison et d’exposer l’incertitude.

L’expérience de Cisco est donc également un test de l’apprentissage organisationnel. Ses perspectives s’améliorent si une petite équipe peut transformer des connaissances éparses en preuves d’acceptation réutilisables. Elles s’affaiblissent si le projet traite les mainteneurs expérimentés uniquement comme des obstacles à une production plus rapide.

Surveillez les preuves issues du pilote, l’acceptation en production et la charge de maintenance

La prochaine mise à jour utile expliquerait ce qui a passé l’évaluation, qui l’a accepté et ce qui s’est produit ensuite.

La réécriture de code par IA de Cisco deviendra plus facile à évaluer grâce à des preuves concrètes au cours des prochains mois. La période de démonstration de quatre semaines rapportée donne aux lecteurs un point de référence à court terme. Toutefois, le reportage n’établit pas sa date de début exacte et ne promet pas de publication publique.

Le premier signal serait une description du périmètre et des résultats du pilote. Les lecteurs devraient rechercher une charge de travail identifiable, un objectif de transformation déclaré et des critères d’acceptation. Ces détails montreraient si l’équipe a testé quelque chose de représentatif de l’ambition plus large.

Une démonstration réussie renforcerait l’argument si elle exposait à la fois les réalisations et les limites. Par exemple, indiquer quelles modifications ont exigé une correction humaine aiderait à établir les exigences réelles du processus. Il s’agit d’une norme de preuve, plutôt que d’une prédiction de ce que Cisco divulguera.

Une démonstration ne montrant que du code nouvellement généré apporterait un soutien plus faible. Elle démontrerait une production sans expliquer la compatibilité ou l’acceptation. La différence importe, car l’objectif à long terme concerne la modification de logiciels existants plutôt que la production d’un exemple autonome.

Le deuxième signal est l’acceptation dans un processus de livraison en production. Les lecteurs devraient rechercher la confirmation que des équipes responsables ont approuvé une transformation délimitée et l’ont déployée. Une procédure de retour en arrière, c’est-à-dire une méthode définie pour restaurer une version antérieure, préciserait davantage la manière dont le programme gère l’échec.

Ce signal renforcerait l’argument de la modernisation, car il relie l’expérience aux responsabilités opérationnelles. Il montrerait que les équipes concernées peuvent évaluer le travail plutôt que de simplement l’admirer. L’approbation devrait toutefois toujours être interprétée dans le périmètre de ce déploiement.

À l’inverse, des démonstrations répétées sans déploiement laisseraient une question centrale sans réponse. Le processus pourrait générer des propositions utiles tout en peinant à satisfaire les exigences d’acceptation. Ce résultat identifierait une contrainte de livraison plutôt que de prouver que chaque transformation manque de valeur.

Le troisième signal est la charge de maintenance après le déploiement. Les lecteurs devraient surveiller les preuves concernant les corrections ultérieures, les besoins de support et la possibilité de retirer l’ancienne implémentation. Ces résultats révèlent si la modernisation réduit le travail ou le déplace simplement ailleurs.

Une modification qui reste stable et simplifie la maintenance future soutiendrait la prémisse du projet. Une modification exigeant une intervention récurrente importante l’affaiblirait. Aucune de ces conclusions ne devrait reposer uniquement sur la rapidité avec laquelle le premier remplacement est apparu.

Ces signaux offrent également un meilleur cadre aux acheteurs d’entreprise qui évaluent les affirmations sur la modernisation par IA. Demandez aux fournisseurs de distinguer les modifications proposées des modifications déployées, puis les modifications déployées des améliorations durables. Exigez suffisamment de détails pour comprendre quelles charges de travail ont produit le résultat rapporté.

Pour les responsables de l’ingénierie, l’action immédiate consiste à examiner un problème de maintenance délimité dans leur propre organisation. Établissez la norme d’acceptation existante, identifiez les personnes qui en comprennent les contraintes et mesurez le parcours complet jusqu’au déploiement. Comparez l’effort de revue et de correction à la vitesse de génération. Consignez les hypothèses qui limiteraient la reproduction du résultat ailleurs. La réécriture de code par IA de Cisco mérite l’attention parce qu’elle teste jusqu’où le soutien de la direction et l’expérimentation sans restriction peuvent étendre la modernisation logicielle. Son importance finale dépendra de ce qui restera fiable après l’enthousiasme initial. Lorsque la prochaine mise à jour arrivera, posez une question concrète : quelle modification acceptée a rendu le logiciel plus facile à maintenir, et quelles preuves étayent ce jugement ?