Moderniser une application iOS pour iPhone Duo sans réécriture automatique

Le lancement du Duo justifie un examen de votre application ancienne, sans imposer son remplacement. Dans sa présentation du produit, Apple décrit un écran intérieur, un écran extérieur et plusieurs positions et orientations. Ces caractéristiques donnent un objet concret à l’audit : vérifier que vos utilisateurs peuvent poursuivre leurs tâches lorsque la présentation change. Elles ne permettent pas de conclure que votre code métier, vos données ou votre serveur doivent être remplacés.

Partez du service rendu aujourd’hui. Quels parcours soutiennent réellement votre activité ? Quelles difficultés existent déjà sur les appareils utilisés ? Un écran ancien mais lisible et fiable mérite une décision différente d’un formulaire dont les champs deviennent inaccessibles. Demandez au prestataire de distinguer les défauts constatés, les risques à vérifier et les préférences de conception. Cette séparation évite de transformer une envie de simplification technique en nécessité commerciale.

Exemple hypothétique : votre application sert à consulter des dossiers et à enregistrer une intervention. La consultation reste satisfaisante, mais le formulaire repose sur des dimensions fixes. Le chantier proposé pourrait conserver la consultation et reprendre la disposition du formulaire. Il faudrait encore vérifier la saisie, la conservation du brouillon et la confirmation d’enregistrement avant d’accepter ce périmètre.

Le maintien constitue donc une option à documenter. Exigez une justification lorsqu’un composant est déclaré impossible à conserver : dépendance bloquante, comportement incorrect ou difficulté de maintenance observable. Une recommandation de réécriture doit expliquer quel problème elle résout et pourquoi une correction locale serait insuffisante. Votre décision porte sur un risque et un usage identifiés, avec les conséquences du maintien clairement décrites. Elle ne découle pas du seul âge de l’application ni de l’arrivée d’un appareil.

Vous pouvez décider du niveau de reprise en reliant chaque difficulté observée au composant qui la provoque. Demandez un inventaire utilisable pour arbitrer : parcours concerné, défaut constaté, cause supposée, vérification nécessaire et intervention proposée. Le prestataire doit pouvoir expliquer pourquoi son choix s’arrête à une correction ou s’étend à un écran ou à un module. Le tableau suivant sert de support à cette discussion ; il ne remplace pas les observations de l’audit.

L’intérêt de cette grille tient à ses limites. Une refonte d’écran ne devrait pas emporter une modification des règles de calcul sans décision explicite. À l’inverse, conserver une interface ne suffit pas si sa dépendance technique empêche toute correction ultérieure. Faites préciser les conséquences de chaque choix sur la maintenance, les tests et la capacité à livrer séparément.

Exemple hypothétique : un écran de recherche présente mal ses filtres, tandis que les résultats restent corrects. Une reprise de présentation pourrait suffire. Si la recherche mélange affichage, requêtes et droits d’accès dans un ensemble difficile à isoler, une intervention sur le module mérite d’être étudiée. Le diagnostic doit apporter les éléments qui permettent de départager ces options.

Demandez également ce qui ferait changer la recommandation. Une dépendance inaccessible, un code manquant ou une règle métier inconnue peuvent déplacer la limite du chantier. Le devis doit indiquer comment cette découverte sera instruite, avec quel livrable et avant quelle décision de poursuite. Vous gardez ainsi la maîtrise du périmètre lorsque l’exploration révèle une difficulté réelle.

Conservez enfin une trace des composants laissés en place et de la raison de ce choix. Ce registre donnera du sens aux demandes futures : il évitera qu’une équipe relance une refonte déjà écartée sans apporter de fait nouveau.

La cible technique doit répondre aux limites établies de votre application et aux usages que vous souhaitez maintenir. La présence de code ancien ne suffit pas à choisir un remplacement. Demandez d’abord quelles parties utilisent SwiftUI, UIKit ou des contenus web intégrés, puis comment elles contribuent aux parcours concernés. Le choix de conserver ou de modifier ces éléments dépend de leur comportement, de leurs dépendances et de leur entretien possible.

Une cible utile décrit une organisation du logiciel : ce qui reste dans l’application, ce qui relève du serveur et ce qui circule entre eux. Si le problème concerne la présentation, la proposition doit expliquer pourquoi elle touche éventuellement une autre couche. Si une dépendance fragilise le module, le prestataire doit décrire son remplacement et les effets attendus sur les fonctions existantes. Refusez les cibles décrites uniquement par une liste de technologies.

Exemple hypothétique : une application présente une aide intégrée dans une vue web et un formulaire natif pour transmettre une demande. L’audit pourrait recommander de conserver cette répartition, tout en corrigeant l’affichage de l’aide et le comportement du formulaire. Rien dans cet exemple ne justifie, à lui seul, de convertir tout le logiciel en application web ou de remplacer son serveur.

Exigez une comparaison écrite des options encore crédibles. Pour chacune, faites préciser les éléments conservés, les éléments remplacés, les contraintes de coexistence et les conséquences pour la maintenance. Une cible qui permet de livrer progressivement peut faciliter la décision, à condition que ses interfaces soient définies. Les guides de préparation d’un projet logiciel peuvent vous aider à formuler ce besoin avant la consultation, puis à demander une justification pour chaque changement de technologie proposé.

Chaque lot doit s’arrêter sur un résultat métier vérifiable et sur des limites techniques écrites. Une liste d’écrans à modifier reste insuffisante si personne ne sait quelles règles, dépendances ou connexions sont incluses. Décrivez la tâche que l’utilisateur doit accomplir, les composants concernés et les comportements à préserver. Le prestataire pourra alors proposer un découpage dont vous pourrez contrôler la livraison.

Pour chaque lot, le document de cadrage devrait identifier les entrées nécessaires, les sorties attendues et les éléments hors périmètre. Ajoutez les conditions de démarrage : accès au code, environnement disponible, comptes de test et personne capable de répondre aux questions métier. Ces conditions rendent visibles les blocages possibles avant qu’ils ne deviennent des échanges sur la responsabilité du retard.

• Associer le lot à un parcours et à un responsable de validation.
• Décrire les modifications autorisées et les comportements à conserver.
• Prévoir les preuves de recette et les conditions de suspension.
• Préciser les éléments remis pour poursuivre la maintenance.

Exemple hypothétique : le lot consacré à la saisie d’une intervention inclut la disposition des champs, la conservation du brouillon et l’affichage de la confirmation. Il exclut une nouvelle règle de facturation. Si cette règle apparaît nécessaire pendant les travaux, elle fait l’objet d’une décision distincte avec ses conséquences sur le périmètre. Cette frontière protège la cohérence du lot sans interdire son évolution.

Vérifiez enfin que le lot peut être accepté sans dépendre d’un chantier laissé indéfini. Si sa livraison suppose une modification serveur, celle-ci doit apparaître dans les engagements et dans la recette. Un lot limité reste un ensemble complet pour l’usage retenu. Son acceptation doit donner une preuve exploitable avant d’engager la suite de la modernisation.

Vous devez définir le comportement des échanges API utilisés par les modules repris avant de modifier leurs consommateurs. L’objectif est de préserver une compréhension commune entre l’application et le serveur. Faites décrire les données envoyées, les réponses attendues, les erreurs possibles et les droits nécessaires. Si aucune modification de ces échanges n’est justifiée, leur conservation doit faire partie du périmètre convenu.

Un contrat API exploitable précise aussi le sens des informations. Un champ absent signifie-t-il une donnée inconnue, une valeur effacée ou un défaut ? Une demande refusée peut-elle être renvoyée ? Après une interruption réseau, comment l’application détermine-t-elle si l’opération a été enregistrée ? Ces questions concernent les échanges réellement présents dans votre projet. Elles ne constituent pas des changements imposés par le nouvel appareil.

Exemple hypothétique : un utilisateur valide une intervention, puis quitte l’écran avant de recevoir la confirmation. Une interface modernisée ne doit pas laisser cette situation sans traitement défini. Demandez comment retrouver l’état de la demande et comment empêcher une répétition involontaire de l’action. Le prestataire doit proposer un comportement vérifiable, compatible avec le fonctionnement du serveur conservé.

La coexistence mérite une attention particulière lorsque des versions différentes de l’application restent utilisées. Faites préciser quels échanges doivent rester acceptés, comment une évolution sera reconnue et quelles conditions permettront d’abandonner un ancien comportement. Le contrat doit également indiquer qui modifie le serveur et qui vérifie les conséquences dans l’application.

À la réception, demandez des exemples d’échanges et des scénarios d’erreur utilisables par votre équipe de maintenance. La documentation seule ne prouve pas leur respect : la recette doit confronter le module modernisé aux réponses prévues, y compris lorsque la connexion ou les droits empêchent l’action attendue.

Les modules anciens et modernisés doivent partager des règles explicites, et les données doivent rester en place tant qu’un déplacement n’est pas justifié. Une adaptation d’interface ne crée pas automatiquement un besoin de migration. Commencez par identifier où les informations sont enregistrées, quels composants les modifient et quelle version fait autorité lorsque plusieurs représentations existent.

La coexistence concerne notamment la session, les droits, la navigation et les informations temporairement conservées sur l’appareil. Demandez ce qui se passe lorsqu’un utilisateur commence une tâche dans un écran conservé puis poursuit dans un module repris. Le passage doit préserver le contexte utile sans créer de divergence sur l’état de la tâche. Faites également décrire les conséquences d’une fermeture de l’application ou d’une perte de connexion.

Exemple hypothétique : un module modernisé consulte les dossiers existants à travers les échanges déjà utilisés. Les données centrales peuvent rester à leur emplacement actuel si leur structure et leur accès conviennent. Si le nouveau module nécessite une représentation différente d’un brouillon local, la migration pourrait se limiter à ce brouillon. Le périmètre doit nommer précisément les informations concernées et expliquer la nécessité du changement.

Lorsqu’une migration est retenue, demandez les règles de correspondance, le traitement des valeurs inattendues et la méthode de contrôle. Il faut pouvoir déterminer ce qui a été repris, ce qui a été rejeté et comment traiter les écarts. La sauvegarde et la restauration doivent être décrites avec les responsabilités associées.

Vérifiez surtout la compatibilité du retour arrière avec les écritures nouvelles. Restaurer une ancienne version de l’application ne suffit pas si elle ne comprend plus les données produites entre-temps. Cette question doit être résolue avant d’autoriser la bascule du module concerné.

Un prix et un calendrier défendables reposent sur des lots décrits, des dépendances identifiées et des conditions de recette convenues. Les informations disponibles ne donnent aucun tarif ni délai permettant de chiffrer votre application. Demandez donc une proposition liée aux constats de l’audit, avec une explication des éléments qui déterminent l’effort. Une enveloppe sans hypothèses écrites ne permet pas de comparer les offres.

Le devis doit distinguer le diagnostic complémentaire éventuel, les modifications, la préparation des environnements, la recette et l’accompagnement de la livraison. Pour chaque poste, cherchez le résultat remis et la condition d’acceptation. Faites préciser le traitement des anomalies découvertes dans le code conservé : certaines bloqueront le lot, d’autres pourront être documentées pour une intervention ultérieure.

Exemple hypothétique : une offre prévoit de reprendre un écran, mais suppose que le serveur accepte déjà les échanges nécessaires. Une autre inclut l’examen de ce point et les corrections convenues. Les intitulés peuvent sembler proches alors que les engagements diffèrent. Comparez les responsabilités et les exclusions avant de comparer les montants qui vous seront proposés.

Le calendrier doit rendre visibles les décisions qui dépendent de vous : validation des parcours, fourniture des accès et disponibilité des personnes chargées de la recette. Demandez comment une incertitude sera levée et comment son effet éventuel sera présenté avant engagement supplémentaire. Une date annoncée sans ces conditions décrit mal le déroulement du chantier.

Pour préparer vos questions, consultez les éléments qui composent le prix d’un logiciel sur mesure. Utilisez ensuite le même périmètre de consultation pour les candidats. Vous pourrez examiner ce que chacun prend en charge, les preuves qu’il remet et les dépenses qui resteraient à décider après le démarrage.

Une livraison progressive devient acceptable lorsque chaque étape possède des critères de recette, une surveillance prévue et une procédure de retour arrière praticable. Le découpage du développement ne suffit pas à maîtriser la mise en service. Vous devez savoir quel changement sera exposé aux utilisateurs, comment reconnaître un incident et qui peut décider de suspendre la diffusion.

Construisez la recette à partir des tâches retenues dans le cadrage. Pour chacune, décrivez l’état de départ, l’action, le résultat attendu et les informations à préserver. Incluez les changements de présentation pertinents pour l’application, puis les interruptions susceptibles de révéler une perte de contexte. Les contrôles doivent aussi couvrir les fonctions conservées qui échangent avec le module repris.

Exemple hypothétique : une personne commence un formulaire, change l’orientation de l’appareil, consulte une information puis revient à la saisie. Le scénario doit préciser ce qui reste renseigné, où revient la navigation et comment la validation est confirmée. Il s’agit d’un contrôle proposé pour votre projet, sans présumer d’un défaut du produit ni d’un résultat déjà obtenu sur appareil.

Demandez que les résultats distinguent les vérifications effectuées, leurs conditions et les points encore ouverts. Une démonstration réussie ne remplace pas cette trace. Le responsable métier doit pouvoir accepter le parcours sur une base compréhensible, tandis que l’équipe technique conserve les éléments nécessaires pour reproduire un écart.

Avant la diffusion, examinez la procédure de retrait du changement. Quels composants peuvent revenir à leur état précédent ? Quelles données doivent être préservées ? Quelles actions demandent une intervention serveur ? Faites vérifier cette procédure dans les conditions convenues. Le droit de suspendre la suite et les responsabilités de remise en service doivent être écrits.

Choisissez une agence sur sa capacité à justifier le périmètre proposé, à examiner votre existant et à contractualiser les vérifications nécessaires. Une présentation générale de développement mobile ne suffit pas à démontrer une aptitude à reprendre votre application. Demandez quelles preuves publiées soutiennent les compétences revendiquées, puis quels éléments devront encore être vérifiés pendant les échanges techniques.

La discussion doit porter sur votre code disponible, ses dépendances, les parcours critiques et les accès nécessaires. Un candidat devrait pouvoir expliquer ce qu’il souhaite inspecter avant de recommander une conservation, une correction ou une reprise plus large. Évaluez la clarté de ses questions et la précision de ses hypothèses. Une proposition crédible laisse apparaître les inconnues qui restent à traiter.

Exemple hypothétique : un candidat propose immédiatement une réécriture complète, tandis qu’un autre demande à examiner la navigation et les échanges serveur avant de délimiter les lots. Demandez au premier quelle observation justifie son périmètre, et au second quel livrable permettra de prendre la décision. L’objectif est d’obtenir des engagements examinables auprès de chacun, sans déduire une compétence d’une formule commerciale.

Faites préciser qui conduira l’audit, qui modifiera le code et qui répondra aux anomalies de recette. Vérifiez les modalités de remise du code, de la documentation, des configurations et des accès nécessaires à la maintenance. La continuité du logiciel après livraison dépend aussi de ces éléments et de leur disponibilité pour votre équipe.

Préparez enfin une demande centrée sur votre décision : ce que vous souhaitez conserver, les difficultés connues et les contraintes d’exploitation. Joignez les questions encore ouvertes sur les données, la coexistence et le retour arrière. Vous donnerez ainsi aux prestataires une base concrète pour cadrer leur réponse. Décrire votre projet logiciel