L'agence préconise deux langages distincts pour iOS et Android — quel impact sur le budget ?

L'impression ticket en bluetooth et le scan de code-barres passent par des bridges natifs parfaitement au point sur les technos cross-platform actuelles. Zéro latence au niveau hardware. Si l'agence insiste sur le double natif, c'est surtout que leurs devs ne maîtrisent pas les outils multiplateformes.

On a fait la même bêtise il y a 3 ans dans notre réseau de distribution de gros : on est partis sur du natif. 240.000 TL de facture. À chaque mise à jour Android ou changement de politique Apple, on repassait à la caisse deux fois. On a tout rebasculé sur une seule base de code l'an dernier, notre maintenance est passée de 18.000 TL à 8.500 TL par mois.

L'agence a sans doute des développeurs iOS et Android dédiés en intercontrat et cherche à facturer leurs jours-hommes sur votre projet. 90 % des applis commerciales B2B sortent aujourd'hui sur une seule base de code.

Avant de signer, exigez des réponses claires : 1) Quels écrans opérationnels s'ouvriront plus vite en natif par rapport à une base unique ? 2) Quel est le périmètre exact de la maintenance annuelle pour deux codes séparés ? 3) La propriété intellectuelle des codes sources des deux plateformes vous sera-t-elle intégralement cédée à la livraison ?

Avant de lâcher 340.000 TL, faites chiffrer le même CDC par deux autres agences spécialisées en cross-platform. Vous verrez le devis redescendre autour de 190.000 TL pour 6 semaines de délai de livraison.

Est-ce que vos commerciaux de terrain vont dans des entrepôts sans réseau ? S'il faut une synchronisation de base de données hors ligne (offline) l'architecture devient un peu plus critique mais même ça, ça se gère très bien avec une seule base de code.

Faire coder en natif dans deux langages séparés une appli B2B qui se contente d'afficher un catalogue et de scanner des codes-barres, c'est purement et simplement jeter l'argent par les fenêtres.

Merci beaucoup je teste dès aujourd'hui. Commencez par un petit test, ne vous engagez pas sur tout d'un coup.

Je le note au cas où.

Chez moi, c'est l'inverse qui s'est passé, c'est pourquoi j'écris. Un rapport d'avancement écrit hebdomadaire est bien plus utile que de demander des dates.

Laissez-moi détailler l'aspect technique. L'offre la moins chère est généralement la moins réfléchie.

À votre place, j'irais par cette voie.

mes doutes sont levés, merci mais avant de décider rgardez quelles données vous avez en main.

Je vais résumer le sujet, car plusieurs réponses différentes ont été données. La réponse varie beaucoup selon le secteur, il n'y a pas de règle générale.

Mettre en place un processus de demande de changement n'ralentit pas le travail, il l'accélère. Bon courage.

Chez nous, ça s'est passé comme ça. La plupart des pertes de temps s'accumulent sur les tâches en attente de validation.

Si vous écrivez le résultat ici, cela aidera aussi d'autres personnes.

j'ai vécu la même chose.

Je suis entièrement d'accord. Les gens défendent l'habitude pas le processus. La résistance vient de là.

Aucun processus sans suivi ne s'améliore, car vous ne savez pas quoi corriger. Voilà désolé si je me suis étendu.

J'aurais une question, sans vouloir m'éloigner du sujet. Si le périmètre s'agrandit, il faut augmenter soit le délai soit le budget. Il n'y a pas de troisième option.

J'espère que cela vous sera utile.

Je partage mon expérience. Lors de la prise de décision, écrivez aussi le pire scénario, pas seulement le meilleur.

Commencez par un petit test, ne vous engagez pas sur tout d'un coup.

Merci pour votre retour.