# ionic : pourquoi une agence native s'intéresse à l'hybride

> Nous sommes spécialisés en développement natif iOS et Android. Pourtant, depuis six mois, on expérimente Ionic. Retour sur ce qui nous a convaincus d'y regarder de plus près.

Date : 12/11/2014
Auteur : Aurélien N.
Tags : Ionic, Mobile, Cordova, AngularJS

---

On fait du natif. C'est notre métier depuis le début — Objective-C sur iOS, Java sur Android, deux codebases, deux équipes, deux cycles de release. On connaît les avantages : performance, accès complet aux APIs système, UX sans compromis. On sait aussi ce que ça coûte.

Depuis six mois, on expérimente Ionic en interne. Pas pour remplacer le natif — pour comprendre où le curseur se place, et pour quels projets ça fait sens. Cet article est un point d'étape.

## Le constat

### Le coût du natif pour les petits projets

On reçoit régulièrement des demandes de clients qui veulent une app mobile. Pas une app complexe — un catalogue produit, un outil de réservation interne, un formulaire connecté à un back-office. Le genre de projet où le budget ne justifie pas deux développements parallèles.

Jusqu'ici, on proposait du natif ou rien. On orientait parfois vers un site responsive, faute de mieux. Mais "faute de mieux" n'est pas une recommandation — c'est un aveu.

### Ce qui a changé

Deux choses ont bougé cette année.

**Les WebViews se sont améliorées.** Sur iOS 8, Apple a introduit `WKWebView` — un moteur JavaScript nettement plus rapide que l'ancien `UIWebView`. Sur Android 4.4, le WebView est désormais basé sur Chromium — un vrai bond par rapport aux versions précédentes. Le fossé de performance entre web et natif se réduit, au moins pour les interfaces classiques.

**Ionic a posé un vrai cadre.** Avant, "hybride" signifiait Cordova + jQuery Mobile, et le résultat ressemblait à ce que c'était : une page web dans une coquille. Ionic est différent. C'est un SDK complet — composants UI natifs en apparence, transitions animées, gestion du routage, intégration AngularJS. Le projet a levé un million de dollars chez Drifty Co., et la bêta tourne depuis mars. La communauté est déjà très active.

## Ce qu'Ionic apporte

### AngularJS comme fondation

On utilisait déjà AngularJS côté web. Retrouver les mêmes patterns — controllers, services, directives, injection de dépendances — dans un contexte mobile, c'est un gain de productivité immédiat. Pas de nouveau langage à apprendre, pas de nouveau paradigme.

Le routing utilise `ui-router` et son système d'états imbriqués. Les vues sont cachées en mémoire — on navigue en avant et en arrière sans recharger, exactement comme une app native avec une pile de navigation.

```javascript
.config(function($stateProvider, $urlRouterProvider) {
    $stateProvider
        .state('app', )
        .state('app.reservations', {
            url: '/reservations',
            views: {
                'menuContent': 
            }
        });
    $urlRouterProvider.otherwise('/app/reservations');
})
```

### Des composants pensés pour le mobile

Ionic fournit une bibliothèque de composants qui imitent les conventions de chaque plateforme : listes avec swipe-to-reveal, pull-to-refresh, tabs, modales, action sheets. Le rendu est fluide — les animations sont accélérées par GPU via CSS transforms.

```html

    
        
        {}
        {}
    

```

C'est du HTML. Un développeur web lit ça et comprend immédiatement. Essayez de montrer un `UITableViewDataSource` en Objective-C à quelqu'un qui vient du web — la courbe d'entrée n'est pas la même.

### Le workflow de développement

`ionic serve` lance un serveur local avec live-reload. On développe dans le navigateur, on itère en secondes. Quand on vient du cycle Xcode — build, deploy sur simulateur, attendre, tester — c'est un choc. L'option `-l` affiche côte à côte le rendu iOS et Android.

```bash
npm install -g cordova ionic
ionic start monApp tabs
cd monApp
ionic serve -l
```

Quatre commandes. Du concept au prototype fonctionnel, on est à l'heure près. En natif, on en est encore à configurer les certificats de développement.

### Cordova et les plugins natifs

Cordova fait le pont entre le JavaScript et les APIs natives — caméra, GPS, notifications push, système de fichiers. L'écosystème de plugins est vaste. La bibliothèque [ngCordova](https://ngcordova.com/) les enveloppe dans des services Angular, ce qui évite les callbacks imbriqués et rend le code testable.

```javascript
$cordovaCamera.getPicture(options).then(
    function(imageData) ,
    function(err) 
);
```

C'est propre. Ce n'est pas aussi puissant qu'un `AVCaptureSession` en natif, mais pour prendre une photo et l'envoyer à un serveur, ça suffit largement.

## Le dilemme

### Ce qu'on sait qu'on perd

On ne va pas se mentir. On vient du natif, on sait ce que le hybride ne peut pas faire — ou pas aussi bien.

**La performance brute.** Les animations complexes, les listes de plusieurs milliers d'éléments, le traitement d'image en temps réel — la WebView a ses limites. Sur les appareils Android d'entrée de gamme, on sent la différence. Le projet Crosswalk embarque un Chromium récent pour contourner la fragmentation Android, mais il ajoute 20 Mo au binaire.

**L'accès aux APIs récentes.** Chaque nouvelle version d'iOS ou Android apporte des APIs que les plugins Cordova mettent des semaines ou des mois à couvrir. L'API Touch ID vient d'être ouverte aux développeurs sur iOS 8 — pas de plugin Cordova stable à ce jour. En natif, on l'intègre le jour de la keynote.

**Le debugging.** Les outils progressent — Safari Remote Debugging pour iOS, Chrome DevTools pour Android — mais on est loin du confort de LLDB dans Xcode ou d'Eclipse ADT. Quand un plugin Cordova plante dans la couche native, on est entre deux mondes.

**Le "uncanny valley".** Une app Ionic bien faite ressemble à une app native. Mais un utilisateur iOS exigeant remarquera que le momentum du scroll n'est pas tout à fait le même, que les transitions sont un poil moins réactives, que le clavier ne se comporte pas exactement comme dans Mail.app. C'est subtil, mais c'est là.

### Ce qu'on y gagne

**Un seul code, deux plateformes.** Pour un budget donné, le client a une app iOS et Android au lieu d'une seule plateforme. Sur les projets à budget serré, c'est l'argument décisif.

**La vélocité.** Le cycle développement-test est incomparablement plus rapide. Live-reload, pas de compilation, debugging dans le navigateur. On itère plus vite, on converge plus vite avec le client.

**La mutualisation des compétences.** Notre équipe web Angular peut contribuer au développement mobile. Pas besoin de recruter un développeur Objective-C *et* un développeur Java pour un projet de trois mois.

**La maintenabilité.** Une seule codebase à maintenir, à mettre à jour, à débugger. Sur la durée, pour un client qui n'a pas d'équipe technique en interne, c'est un avantage considérable.

## Notre approche

### Six mois d'expérimentation

On a commencé par un projet interne — un outil de suivi de temps. Rien de critique, mais assez complet pour tester les cas réels : authentification, requêtes API, stockage local, notifications.

Ce qu'on a appris :

1. **Les performances sont suffisantes pour 80% des projets qu'on reçoit.** Catalogues, formulaires, dashboards, outils internes. Pas de jeu 3D, pas de traitement vidéo — des apps métier.

2. **Le temps de développement est divisé par deux** par rapport à un double développement natif. Pas par rapport à un développement natif mono-plateforme — soyons honnêtes.

3. **La courbe d'apprentissage est douce** pour quelqu'un qui connaît Angular. Quelques jours pour être productif, quelques semaines pour maîtriser les subtilités de Cordova.

4. **Les limites sont prévisibles.** On sait à l'avance quand un projet va buter contre le plafond du hybride. Ce n'est pas une surprise en cours de route.

### Ce qu'on propose aujourd'hui

On commence à proposer Ionic à certains clients. Pas à tous — à ceux dont le projet correspond au profil.

**Ionic fait sens quand :**
- Le budget ne permet pas deux développements natifs
- L'app est principalement de la consultation de données et des formulaires
- Le client veut une présence iOS + Android rapidement
- L'équipe de maintenance côté client est web, pas mobile

**On reste en natif quand :**
- L'app a des besoins forts en performance ou en graphisme
- Elle utilise des APIs système avancées (Bluetooth LE, CoreMotion, HealthKit)
- L'UX doit être irréprochable sur une seule plateforme
- Le client a déjà une équipe mobile en interne

On ne vend pas Ionic comme "du natif moins cher". On le présente comme une alternative pragmatique, avec ses compromis, pour des projets où le rapport coût/couverture est l'enjeu principal.

## La suite

Ionic 1.0 stable devrait sortir dans les prochains mois. L'équipe de Drifty bouge vite — le CLI s'améliore à chaque release, les composants se multiplient, la documentation est déjà excellente. On garde un oeil sur les Web Components et sur ce que Google prépare avec Polymer, mais pour l'instant, Ionic + AngularJS est la combinaison la plus mature.

On reste une agence native. On le restera. Mais ignorer ce qui se passe côté hybride, en 2014, ce serait de l'aveuglement. Le web rattrape son retard sur le mobile, et les outils comme Ionic accélèrent cette convergence.

La vraie question n'est plus "natif ou hybride". C'est "pour ce projet, à ce budget, avec ces contraintes — lequel ?"

On préfère avoir la réponse honnête plutôt que la réponse confortable.

---

*Mise à jour : on a fini par utiliser Ionic en production sur un vrai projet client — [Hively, une marketplace de services](/blog/beespoke-marketplace-collaborative-ionic-rails). Le retour d'expérience a confirmé l'intuition de cet article : pour le bon projet, c'est le bon outil.*