Application grand public
Donino
En ligneUne application de dons entre particuliers au Maroc, conçue pour publier, rechercher et réserver des objets près de chez soi.
100K+ téléchargements sur Google Play
- iOS
- Android
Cycle de vie mobile
Votre application est lancée.
Sa vie commence.
Nous préparons les publications, organisons les versions et cadrons la maintenance nécessaire pour que l’application reste compatible, compréhensible et évolutive après son lancement.
Version mobile1.4.0 · Build 72
Prête à testerRelease candidateVérifications terminées
Fonctions ✓Compatibilité ✓Fiche store ✓
AppleApp Store
Soumission préparée
GoogleGoogle Play
Version préparée
Distribution
App Store & Google Play
Versions
Builds signés & traçables
Compatibilité
OS, appareils & services
Évolution
Produit suivi après lancement
Sélection 2026 · Applications en production
Des applications publiées et suivies après leur lancement.
La mise en ligne ne termine pas le projet : versions, compatibilité et corrections accompagnent la vie réelle de chaque application.
Faites glisser pour découvrir
Utilitaire iOS
Keeper
En ligneUn inventaire domestique visuel pour retrouver ses objets par emplacement, recherche Spotlight et QR codes, même hors connexion.
Publiée par AL MISBAH INFORMATIQUE
- iOS
Productivité iOS
Strike
En ligneUne application de suivi d’habitudes et de concentration avec alarmes, statistiques, widgets et expérience Apple Watch.
Publiée par AL MISBAH INFORMATIQUE
- iOS
- Apple Watch
Application métier
OLABLANCA 2
En ligneUn espace mobile réservé aux copropriétaires pour suivre cotisations, réclamations, documents, événements et projets.
Publiée par AL MISBAH INFORMATIQUE
- iOS
- Android
Cette sélection présente uniquement nos applications réalisées en 2026. Notre historique mobile comprend aussi de nombreux projets livrés en 2025, 2024 et les années précédentes.
Avant les stores
Publier n’est pas simplement déposer un fichier.
La version technique, l’identité de l’éditeur, les informations publiques et les déclarations liées aux données doivent raconter le même produit.
Comptes éditeur
Entreprise porteuse, contrats, accès et responsabilités définis avant la soumission.
Signature & versions
Identifiants, certificats, profils et numéros de build cohérents pour chaque plateforme.
Confidentialité
Données collectées, permissions, finalités et informations de support préparées.
Fiches publiques
Nom, description, visuels, catégories et textes alignés avec l’application réelle.
Chemin d’une version
Une version traverse plusieurs portes avant le public.
Les étapes évitent de confondre une version compilée, une version testée, une version soumise et une version réellement disponible.
- 01
Construire
Générer un build identifié avec les paramètres de l’environnement visé.
- 02
Tester
Vérifier le parcours, les appareils ciblés et les changements de la version.
- 03
Préparer
Mettre à jour la fiche, les déclarations et les notes nécessaires.
- 04
Soumettre
Envoyer la version et répondre aux éventuelles demandes de la plateforme.
- 05
Distribuer
Organiser la disponibilité après validation, selon les options du store.
Responsabilités
Nous préparons la soumission. Les stores gardent la décision.
Une préparation rigoureuse réduit les ambiguïtés, mais aucune agence ne peut remplacer les contrôles ou garantir la décision finale d’Apple et de Google.
Préparer, vérifier, soumettre.
- Version et paramètres de distribution
- Éléments techniques et fiche store
- Réponses aux retours liés au produit livré
- Nouvelle soumission lorsque cela est nécessaire
Contrôler, demander, accepter ou refuser.
- Application des règles du moment
- Demandes d’informations complémentaires
- Délais de revue variables
- Décision finale indépendante du prestataire
Après le lancement
Corriger. Rester compatible. Faire évoluer.
La maintenance n’est pas une promesse vague. Chaque type de changement possède une cause, une priorité, un périmètre de test et une version à livrer.
Les types de maintenance d’une application mobile
Rétablir le fonctionnement attendu.
Qualifier l’anomalie, mesurer son impact, reproduire le comportement et livrer une correction testée.
S’adapter à l’écosystème.
Traiter un changement d’iOS, d’Android, d’appareil, de dépendance, de permission ou de service connecté.
Faire progresser le produit.
Cadrer une nouvelle fonction ou un parcours modifié comme une évolution du produit, avec ses propres validations.
Compatibilité
L’écosystème bouge, même lorsque l’application ne change pas.
Systèmes, appareils, bibliothèques, règles des stores et services externes évoluent indépendamment du produit. Leur impact doit être vérifié avant qu’il ne devienne visible pour les utilisateurs.
Revoir les enjeux iOS & AndroidiOS & Android
Nouvelles versions, comportements modifiés, permissions et exigences techniques.
Appareils
Tailles, performances, capteurs et caractéristiques du parc réellement ciblé.
Dépendances
Bibliothèques, SDK et outils de construction à suivre ou remplacer lorsque nécessaire.
Services externes
API, paiement, authentification, messages ou cartes qui peuvent faire évoluer leurs contrats.
Anomalies & incidents
Un incident commence par une qualification.
Sans version, appareil, contexte et étapes de reproduction, une correction risque de viser le mauvais problème. Le diagnostic organise la priorité avant de modifier le code.
- 01
Identifier
Version de l’application, plateforme, appareil, compte et moment du problème.
- 02
Reproduire
Étapes, données, réseau, permissions et conditions nécessaires au comportement.
- 03
Prioriser
Impact, nombre d’utilisateurs, contournement possible et risque métier.
- 04
Corriger & vérifier
Modification ciblée, tests concernés et nouvelle version préparée si nécessaire.
Versions & qualité
Savoir exactement ce qui part en production.
Une version doit être identifiable, reliée à ses changements et vérifiée sur un environnement cohérent. Les options de distribution progressive sont utilisées lorsqu’elles sont disponibles et pertinentes.
CodeVersion identifiée
ContenuChangements connus
Release candidateTESTÉE & DOCUMENTÉE
Fonctions concernées, appareils ciblés, éléments de publication et décisions de mise en ligne réunis.
TestsRégression ciblée
DistributionDéploiement maîtrisé
Propriété & continuité
Les accès critiques ne doivent pas vivre dans une seule tête.
Comptes éditeur, code, signature et services connectés doivent être attribués, documentés et transmis avec des responsabilités compréhensibles.
Comptes du client
Les fiches et l’historique restent rattachés à l’organisation qui porte le produit.
Accès nominatifs
Les personnes ou prestataires reçoivent les rôles nécessaires sans partager un seul compte.
Code versionné
Les sources et versions publiées restent identifiables pour faciliter le suivi ou la reprise.
Procédure de release
Les étapes, paramètres et responsabilités de publication sont documentés au niveau utile.
Notre méthode
Préparer le lancement. Organiser la suite.
La publication et la maintenance sont cadrées avec le même niveau de clarté que le développement : périmètre, responsabilités, versions et décisions visibles.
- 01
Préparer
Comptes, version, informations, tests et conditions de distribution.
- 02
Publier
Soumission, retours éventuels des stores et décision de mise à disposition.
- 03
Suivre
Signaux disponibles, retours qualifiés, compatibilité et priorités du produit.
- 04
Maintenir & évoluer
Corrections, adaptations et nouvelles versions selon le cadre convenu.
Questions fréquentes
Les réponses avant et après la publication.
Stores, comptes éditeur, informations à préparer, maintenance, fréquence des versions, reprise et types d’évolution.
Accompagnez-vous la publication sur l’App Store et Google Play ?
Oui. Nous pouvons préparer les versions, les éléments techniques, les informations nécessaires aux fiches et accompagner le processus de soumission sur les comptes éditeur du client. Le périmètre exact dépend de l’application, des plateformes et de l’état des comptes.
Pouvez-vous garantir l’acceptation de l’application par Apple ou Google ?
Non. Nous préparons l’application et les informations demandées, puis nous pouvons traiter les retours techniques ou éditoriaux. Apple et Google conservent toutefois la décision finale et peuvent faire évoluer leurs règles ou demander des précisions supplémentaires.
À qui doivent appartenir les comptes développeur Apple et Google ?
Nous recommandons que les comptes appartiennent à l’entreprise qui porte l’application. Elle conserve ainsi la propriété des fiches, des accès et de l’historique des versions. Des accès adaptés peuvent ensuite être accordés aux personnes chargées de la publication.
Quelles informations faut-il préparer pour les stores ?
Les plateformes demandent notamment l’identité de l’éditeur, les coordonnées de support, la description, les visuels, la classification, les informations de confidentialité et les déclarations liées aux données ou aux permissions. La liste précise dépend des fonctions de l’application.
Que couvre la maintenance après la publication ?
Le périmètre peut couvrir la correction d’anomalies, la compatibilité avec de nouvelles versions, le suivi des dépendances, l’adaptation à certains changements de services externes et la préparation de nouvelles versions. Les délais, priorités et canaux de traitement sont définis dans le cadre d’accompagnement.
À quelle fréquence faut-il mettre à jour une application mobile ?
Il n’existe pas de fréquence universelle. Une mise à jour peut être déclenchée par un besoin utilisateur, une correction, une évolution métier, une nouvelle version du système, une dépendance, une exigence du store ou un service externe. Le suivi doit donc être organisé selon le risque et l’usage.
Pouvez-vous reprendre la maintenance d’une application développée ailleurs ?
Une reprise est possible après un audit du code source, des comptes éditeur, des certificats, des dépendances, des services connectés, des versions publiées et de la documentation disponible. Cet audit permet d’identifier les risques et le niveau de remise à niveau nécessaire.
Quelle différence entre maintenance corrective, compatibilité et évolution ?
La maintenance corrective traite un comportement qui ne correspond pas au fonctionnement attendu. La compatibilité adapte le produit à un changement de plateforme, d’appareil, de dépendance ou de service. L’évolution ajoute ou transforme une fonction et nécessite donc un nouveau cadrage produit.
Une version à publier ou une application à reprendre ?
Commençons par l’état réel du produit.
Partagez-nous les plateformes, les versions publiées, les accès disponibles et le besoin actuel. Nous identifierons les vérifications nécessaires avant la prochaine action.