Le choix du langage pour une appli iOS influence-t-il le devis de l'agence et le budget de maintenance ?

Vous avez bien défini ce que l'application doit faire exactement ? Est-ce qu'il y aura de la lecture de code-barres en Bluetooth, du suivi GPS en temps réel en arrière-plan ou des animations complexes avec la caméra ? S'il s'agit juste d'opérations basiques sur base de données comme lister des produits, valider des commandes et envoyer des notifications, ça ne vaut peut-être pas le coup de payer les 110.000 TL de différence pour du natif. En revanche, s'il y a une grosse intégration matérielle, le cross-platform vous coûtera bien plus cher par la suite.

L'année dernière, on a fait développer une appli de commande similaire. On est partis sur du cross-platform pour 180.000 TL, la première année s'est passée sans souci. Mais après une mise à jour de l'OS, le module de scan de code-barres par caméra a planté. L'agence nous a expliqué que la lib open source utilisée n'était plus maintenue et qu'il fallait réécrire le module de zéro, nous demandant 45.000 TL de rallonge. Plus de la moitié de l'économie initiale est partie dans un simple correctif.

Cette idée sur le marché selon laquelle le natif est forcément plus robuste est un peu exagérée. Aujourd'hui, même les applis bancaires et les gros e-commerces font tourner une bonne partie de leurs écrans en cross-platform ou avec des interfaces web. Plus que le langage utilisé par l'agence, c'est l'expérience de l'équipe sur ce langage qui compte. Une appli native mal architecturée générera bien plus de frais de maintenance qu'un cross-platform proprement conçu.

D'un point de vue technique, le vrai point de vigilance, c'est la gestion des dépendances. Dans les technos cross-platform, il y a une couche passerelle (bridge) entre le cœur de l'appli et l'OS. Cette couche peut accuser un temps de retard à chaque mise à jour majeure du système. Demandez à l'agence combien de plugins tiers ils comptent utiliser en dehors des gestionnaires de paquets officiels. Plus il y a de plugins externes, plus vos coûts de maintenance futurs vont exploser.

Les clauses à faire impérativement figurer dans le cahier des charges avant de négocier avec l'agence : 1) Le code source doit respecter les standards de clean architecture et être intégralement commenté. 2) L'obligation d'utiliser une version récente et avec support à long terme (LTS) du langage choisi. 3) La liste complète des licences et versions de toutes les dépendances externes à la livraison. 4) Un guide de déploiement pas-à-pas pour qu'une autre équipe puisse reprendre le projet si l'agence cesse son activité.

on a eu exactement le meme dilemme et quand on a cherché des freelances par la suite on s'est rendu compte d'un truc : bcp de dev hybrides debutent et connaissent a moitie les deux plateformes. quand ca a plante on a ete obliges de repasser sur du natif. genre si le budget suit et que vous visez uniquement ios partir sur du natif propre direct ca evite les prises de tete.

Lors de l'évaluation des devis, il ne faut pas dissocier le périmètre du contrat de maintenance du langage retenu pour le projet. Quelle que soit la technologie, l'intégration d'un engagement de niveau de service (SLA) et le gel du montant mensuel de maintenance vous prémuniront contre un éventuel turnover chez les développeurs ou les montées de version. Veillez également à stipuler sans réserve la cession totale de la propriété intellectuelle du code dans le contrat.

Il y a deux ans, on a choisi la solution low cost pour une appli de vente en gros similaire. On s'était dit : après tout, c'est juste un catalogue basique et une prise de commande. L'agence a livré le boulot et a fermé huit mois plus tard. On a confié le code à un autre dev. Le gars a ouvert le projet et nous a dit que c'était codé sur une vieille version de framework qui n'était plus du tout supportée, et que ça coûterait moins cher de tout refaire à zéro que de corriger. Ce jour-là, on a compris qu'il ne fallait pas seulement regarder le langage, mais aussi sa pérennité.

Exact. Les accès doivent être créés au nom de l'entreprise, pas avec des comptes personnels.

Les solutions qui fonctionnent à petite échelle s'effondrent en grandissant, j'ai appris cela trop tard. Si vous écrivez le résultat ici, cela aidera aussi d'autres personnes.

Merci c'était exactement la réponse que je cherchais. Quand on décide sans mesurer on revient toujours au même point.

J'espère que cela vous sera utile.

vous avez raison.

Vous avez raison. Dans un système repris, le plus coûteux sont les dépendances inconnues.

C'est confirmé par l'expérience.

Laissez-moi détailler l'aspect technique. Quand on essaie de tout changer en même temps, rien ne prend.

La plupart des pertes de temps s'accumulent sur les tâches en attente de validation. À votre place, j'irais par cette voie.

pourriez-vous préciser un peu ? bon ce que tout le monde fait ne signifie pas que c'est la bonne chose.

bon courage.

Pourriez-vous préciser un peu ? L'offre la moins chère est généralement la moins réfléchie.

C'est mon avis, je ne l'écris pas comme une vérité absolue.

Je parle du point de vue du fournisseur, c'est mon côté. Tous ceux qui se pressent sur langage application ios se heurtent au même obstacle.

Je suis aussi curieux de savoir si d'autres font autrement.

Je n'ai aucune expérience en langage application ios, c'est pourquoi je pose la question. Essayer de faire cela seul est la voie la plus coûteuse.

Il y a un point qui m'interpelle. Mettre en place un processus de demande de changement n'ralentit pas le travail, il l'accélère.

C'est mon avis, je ne l'écris pas comme une vérité absolue.