Construire HelioPeak : leçons du développement iOS indépendant

Quelques mois de soirées et de week-ends, six langues, trois plateformes, un développeur. C'est en une phrase l'histoire derrière HelioPeak. Cet article porte sur à quoi cette histoire ressemblait vraiment en pratique : ce qui a bien marché, ce qui était difficile, ce que j'ai appris sur le développement iOS indépendant en 2026, et quelles petites décisions se sont avérées étonnamment grandes.

C'est un peu plus personnel que les autres articles de cette série. Qui n'a pas d'intérêt pour les coulisses d'une petite app, pourrait sauter ceci. Qui a : j'essaie d'être honnête sur ce qu'implique un projet solo à cette époque, sans les clichés typiques de "il faut juste suivre sa passion" ou "ça coûte moins que ce que vous pensez". Les deux sont généralement de fausses simplifications.

Le point de départ

Je ne suis pas développeur Swift de formation. Mon parcours est IT, infrastructure, architecture système, pas mobile development. Je n'avais jamais publié d'app iOS avant HelioPeak. Mon compte Apple Developer datait de plus tôt mais n'avait jamais été utilisé pour publication. Mon expérience Swift se limitait à quelques heures d'expérimentation avec SwiftUI en 2024.

Pourtant, je voulais faire une app iOS spécifique : un client PVOutput correct pour moi-même. Les apps existantes ne faisaient pas exactement ce que je voulais, et parce que j'ai assez de bagage technique pour ne pas les trouver impossibles, j'ai décidé une soirée de janvier 2026 d'en construire une.

Le raisonnement était simple : l'échelle est petite (une personne qui suit son énergie solaire), la complexité semble gérable (un tableau de bord, des graphiques, de la configuration), et j'ai un outillage IA disponible qui peut aider à adoucir la partie courbe d'apprentissage Swift. Pire des cas : j'apprends quelque chose de nouveau et ne publie jamais d'app. Meilleur des cas : j'ai quelque chose que j'utilise avec plaisir moi-même.

L'assistance IA

Voici la première chose sincère que je veux dire : sans Claude (l'outil IA que j'utilise), ce projet n'aurait probablement pas existé. Pas parce que l'IA a tout fait à ma place, mais parce qu'il a rendu le seuil d'apprentissage assez bas pour persévérer les soirs où après une journée de travail je n'avais plus l'énergie de lire un tutoriel Swift.

Ce que l'IA fait en pratique :

• Générer le boilerplate. SwiftUI a beaucoup de patterns récurrents (NavigationStack, sheet, gestureRecognizer). Une IA qui connaît ces patterns économise beaucoup de saisie.
• Suggérer des traductions entre frameworks. "Comment fait-on un flou derrière cet élément ?" ou "Quelle est l'alternative moderne à cette API obsolète ?" sont des questions auxquelles l'IA a souvent immédiatement la bonne réponse, plus vite que Stack Overflow.
• Proposer des considérations d'architecture. Quand vous n'êtes pas sûr si une fonctionnalité appartient à un view-model ou à un service séparé, une IA peut vous faire réfléchir là-dessus et formuler nettement les pros et cons.
• Décortiquer les messages d'erreur. Les error messages de SwiftUI sont notoirement mauvais. Une IA qui peut lire la stack-trace et expliquer la vraie erreur, économise des heures.

Ce que l'IA ne fait pas :

• Prendre les décisions d'architecture à ma place. Cela reste mon travail. L'IA suggère des options ; je choisis laquelle correspond à où je veux aller.
• Trouver des bugs dans mon propre code. Une IA n'est pas meilleure que moi pour lire ma propre logique. Il peut aider, mais la session de debug finale est toujours manuelle.
• Remplacer l'expérience de test sur appareil réel. Ce qui a l'air bien sur un simulateur sur un Mac, échoue parfois sur un vrai iPhone 13 mini. Vous ne voyez cela qu'avec le téléphone en main.
• Déterminer la direction produit. Ce qu'HelioPeak devrait ou ne devrait pas faire, quelle tarification, quelles priorités dans les fonctionnalités, ce sont des décisions où aucune IA ne peut vous remplacer.

C'est j'espère une déclaration non surprenante, mais je pense qu'il est important d'être honnête à ce sujet. L'IA a probablement doublé ou triplé ma productivité. Il n'a pas remplacé mon travail.

Ce que j'ai sous-estimé dans la planification de production

Choses que j'ai fondamentalement mal estimées en temps :

L'internationalisation. J'ai conçu HelioPeak dès le début en six langues, parce que je savais que je voulais adresser les marchés belge, néerlandais, français, allemand, italien et espagnol. C'est une décision fondamentalement correcte au niveau du produit (le multilinguisme est un de mes différenciateurs les plus clairs). Mais le coût opérationnel, je l'ai énormément sous-estimé.

Chaque nouvelle string UI que j'écris doit passer par six traductions. Chaque petite adaptation UI peut casser une traduction qui devient trop longue pour le bouton. Chaque nouvel écran requiert une revue de traducteur. Ce n'est pas un coup à faire une fois ; c'est un fardeau continu qui grandit avec chaque release. Je travaille à mieux industrialiser cela, mais je commence seulement maintenant à comprendre combien de travail multilingue dev représente vraiment.

Le processus app store d'Apple. La première soumission d'HelioPeak a été refusée par une developer review que je n'avais pas attendue. Le feedback de review était assez spécifique et résoluble, mais tout le processus (build, soumettre, attendre, refus, fix, resoumettre, attendre, approbation) a coûté deux semaines. C'est deux semaines en plus dans chaque cycle de release que je ne planifie pas à l'avance. Pour la première release, c'était un choc ; pour les releases suivantes, j'ai mieux calibré mon timing.

Compliance vie privée et privacy nutrition labels. Les exigences d'Apple pour politique de confidentialité, App Tracking Transparency, privacy nutrition labels, et choses connexes sont tous des documents et formulaires qui semblent petits à l'œil mais demandent des heures de travail pour être remplis correctement. Pour qui veut être honnête et transparent sur ce que fait l'app, c'est du temps bien utilisé, mais c'est bien du temps qui n'est mentionné dans aucun "indie dev tutorial".

Marketing et découverte. Faire une bonne app est une chose. Trouver des gens qui veulent l'utiliser est une chose toute différente. C'est un aspect que j'apprends encore, et pour lequel j'ai planifié bien trop peu de temps. Des publications sur Tweakers, le forum PVOutput, Reddit, et des groupes Facebook spécifiques à l'énergie solaire amènent quelques premiers utilisateurs, mais une croissance exponentielle demande quelque chose de plus systématique.

Ce que j'ai sous-estimé en détail technique

Tester sur appareil réel est irremplaçable. Développer SwiftUI sur le simulateur Mac ne se sent guère différent de développer pour le vrai téléphone, jusqu'à ce que ce soit différent. Problèmes de performance, pression mémoire, impact batterie, layouts qui ont l'air différents sur un vrai iPhone 13 mini que sur un simulateur mac-iPhone-13-mini, ce sont toutes des raisons de tester régulièrement sur un vrai téléphone.

Les widgets sont plus difficiles qu'ils n'en ont l'air. Les widgets iOS sont un sous-projet à part dans chaque app. Ils tournent dans un processus séparé, avec leur propre cycle de vie, avec une mémoire et un temps CPU strictement limités. Ce qui marche dans l'app principale ne marche pas nécessairement dans un widget. L'architecture widget dans HelioPeak m'a probablement donné plus de mal de tête que n'importe quelle autre partie de l'app, mais le résultat (un widget sur l'écran de verrouillage ou l'écran d'accueil qui est vraiment utile) est une des fonctionnalités les plus appréciées dans le feedback des utilisateurs.

La localisation des dates, nombres, et devises est un champ de mines. "5.400 kWh" en style néerlandais est "5.400" avec point comme séparateur de milliers ; "5,400" avec virgule comme séparateur de milliers en style anglais signifie littéralement 5,4 en style néerlandais. Le bon traitement de cela dans tous les coins d'une app, dans les six langues, était plus de travail que ce que j'avais estimé.

Swift Charts d'Apple est brillant mais incomplet. Pour mes graphiques, j'utilise le framework SwiftUI Charts d'Apple. Il est excellent pour la plupart des use-cases, mais il manque des cas limites (ratios d'aspect spécifiques à l'export, gradients spécifiques, sub-axis labels) que j'ai dû résoudre avec des combinaisons de Charts natif et d'overlays custom.

Ce que j'ai appris sur le pricing indé

Mon approche du pricing d'HelioPeak a changé au fil du temps. Au lancement initial en avril 2026, l'IAP était de 2,99 €. C'était trop bas, et je le savais. Pour la version 2.0, je l'ai monté à 6,99 €, et même cela sent un peu bas étant donné la valeur que les gens tirent de l'app sur 25 ans.

Le raisonnement derrière le prix :

• Trop bas au démarrage. 2,99 € rendait le seuil bas pour que les utilisateurs testent, mais sans prix de break-even honnête. À ce prix j'aurais besoin de 100.000 utilisateurs pour couvrir mes heures de développement à un salaire horaire normal. Impossible dans cette niche.
• Honnête au relancement. 6,99 € est encore sous ce que des apps comparables demandent (PV Output est un abonnement de 25 $/an, ce qui sur 25 ans devient 600+ €). Mais c'est un prix honnête pour ce que l'app livre, sous forme unique.
• Engagement no-subscription. L'app core reste un achat unique. Un tier Pro vient plus tard pour les fonctionnalités qui apportent de vrais coûts serveur (forecasting, agrégation multi-systèmes), mais la base reste un achat unique de 6,99 € pour qui l'achète ou qui l'a déjà.

Ce que j'ai appris sur les taux de conversion : le pourcentage d'utilisateurs gratuits qui convertissent vers payé est bas (entre 3 et 8 % dans mes données jusqu'à présent). Cela signifie que votre revenu moyen par utilisateur se situe dans la fourchette 0,20 à 0,55 €, pas les 6,99 € que vous penseriez. Pour un marché de niche comme le monitoring solaire, cela signifie qu'un vrai break-even n'est possible qu'à des nombres d'utilisateurs dans les milliers, pas dans les dizaines.

Ce que j'ai appris sur les utilisateurs

Les utilisateurs HelioPeak sont un groupe étonnamment spécifique. Quelques observations :

Ils sont plus âgés que je ne pensais. Moyenne 50+, hommes, techniquement instruits, propriétaires de panneaux solaires depuis 5+ ans. Pas la démographie la plus hippie pour le marketing d'app, mais un groupe avec le temps et les moyens d'acheter une app correcte et de l'utiliser vraiment.

Ils ont de vraies attentes de qualité. Les bug reports sont précis, détaillés, techniquement étayés. Un bug report typique d'un utilisateur HelioPeak décrit non seulement ce qui n'a pas fonctionné, mais aussi quel appareil et quelle version iOS, et de préférence des étapes reproductibles. Cela rend mon travail beaucoup plus facile et c'est quelque chose que je manquerais dans une app plus mainstream.

Ils sont orientés communauté. Beaucoup de feedback arrive via forums (Tweakers en Flandre, PVOutput.org internationalement) plutôt que mail direct. Une conséquence est que les fonctionnalités qui circulent dans la communauté, et que je n'avais pas pensées, s'avèrent parfois très vite être un souhait de beaucoup de gens. La fonction Notes est venue presque entièrement de discussions de forum.

Ils sont fidèles si vous le faites bien. Une fois que quelqu'un a acheté l'IAP, il reste généralement. Le churn dans un modèle achat unique est de toute façon bas, mais dans une niche avec un public spécifique encore plus bas. C'est joli pour le tableau financier à long terme, mais cela signifie aussi que le feedback négatif pèse amplifié : si je perds un groupe de 20 premiers adoptants, cela me touche considérablement plus que dans une app mainstream.

Les petites leçons que j'ai trouvées inopinément précieuses

Quelques petites choses qui ne semblent pas être une "lesson learned" mais qui pour moi ont eu de l'impact :

Écrire un script de commit. J'ai pour mon projet un shell-script qui après un bon build stable commit automatiquement vers Git avec un message standardisé, push vers GitHub, et tient un log des versions. Cela sonne trivial, mais éliminer ce surcoût mental à chaque commit de release a rendu le travail sensiblement plus léger.

Intégrer TelemetryDeck dès le début. Des statistiques d'usage anonymes (quels écrans, quelles actions, quelles versions OS) sont cruciales pour prendre des décisions produit. Pour TelemetryDeck j'ai choisi leur modèle privacy-aware (signals hachés, pas d'identifiants, tenant UE), ce qui supporte à la fois ma ligne éthique et mon récit marketing.

Notes pour moi-même dans le code. Au-dessus de chaque fichier de code non trivial, j'écris ce que fait le fichier, quelles limitations il a, quelles modifications récentes j'ai apportées. Pour mon moi futur, trois mois plus tard quand je reviens à ce fichier, c'est une archive en or. Quiconque est déjà revenu à du vieux code sait ce que je veux dire.

Tester avec de vrais utilisateurs avant d'être vraiment prêt. J'ai laissé ma femme, mon frère, et quelques collègues tester la bêta, et leur feedback avant le launch v1.0 m'a probablement économisé des semaines de travail ensuite. Une heure de test par quelqu'un qui n'est pas développeur, livre plus d'aperçu que dix heures de QA propre.

Ce qui reste

À ce moment, j'ai quelques centaines d'utilisateurs d'HelioPeak, avec de bons avis sur l'App Store, une communauté active sur Tweakers, et un long backlog de fonctionnalités que je veux construire. C'est, en absolu, un petit résultat dans le pays de l'app-store. En personnel, pour quelqu'un qui a commencé sans expérience Swift, cela sent comme une réussite.

Ce que je retiens surtout de ce projet, et ce que je recommanderais à quiconque a des ambitions indépendantes similaires :

Commencez par quelque chose dont vous ressentez vous-même le besoin. Personne d'autre n'est un utilisateur de test plus fiable que vous-même.

Comptez avec des estimations de temps réalistes. Ce qui semble exécutable en une heure en temps de code, coûte souvent cinq heures si vous comptez tout à côté (testing, debugging, documentation, marketing).

Gardez le cycle d'itération court et ne vous souciez pas trop de la perfection dans la version 1. Le plus important est de mettre une chose entre les mains des utilisateurs, parce que le feedback de vraies personnes déplace votre compréhension de ce qui est important plus vite que n'importe quelle planification à l'avance.

Construisez avec la vie privée et avec la qualité en tête dès le début. C'est plus difficile d'ajouter ces principes à un produit existant que de les mettre dès le jour un dans l'architecture.

Et n'ayez pas peur d'être honnête sur ce que votre app ne fait pas. Une app qui dit "voici trois choses que je fais bien, voici cinq choses que je ne fais pas" éveille souvent plus de confiance qu'une app qui prétend tout faire.

Pour terminer

HelioPeak n'est pas une histoire de succès au sens financier (pas encore), mais c'est bien une histoire de succès au sens personnel : j'ai construit quelque chose que je voulais, publié en six langues, sur trois plateformes, à temps, et il est apprécié par de vraies personnes. Pour un développeur sans expérience iOS préalable, ce n'est pas un mauvais résultat de quelques mois de soirs-et-week-ends de travail.

L'horizon suivant est une version Apple Watch, un tier Pro avec intégration Forecast.Solar, et finalement plus de langues. Si ça devient un jour un gagne-pain, reste une question ouverte. Mais si ça ne le devient pas, j'ai encore une bonne app, une communauté grandissante, et un hobby dans lequel je me suis perfectionné comme rarement avant.

C'est peut-être alors la plus grande leçon cachée du développement indépendant : construire est en soi déjà la peine, peu importe où ça atterrit finalement.