Pour analyser une activité liée à l’IA, je distinguerai d’abord trois choses : combien paie le client, combien l’entreprise conserve, et ce qu’une personne détenant un certain type d’actif peut obtenir en retour.
Entre ces couches, on ne peut pas assimiler tout cela à un simple « croissance du secteur de l’IA ». La divulgation publique de Photo AI tombe justement à point pour faire le tri des postes une fois.
D’abord : deux chiffres bien présentés ne peuvent pas être additionnés
Le 6 mars 2026, le fondateur Pieter Levels a déclaré : Photo AI génère 105 000 $ de revenus mensuels et 80 000 $ de bénéfice mensuel. Il s’agit d’une divulgation historique, non auditée de manière indépendante ; les coûts complets selon un périmètre complet pour le bénéfice ne sont pas détaillés. [1]
le 9 septembre, il l’a encore précisé : plusieurs services ont été remplacés par des outils qu’il a lui-même mis en place. Environ 25 000 $ d’économies par mois. Parmi elles, le redimensionnement des images représente environ 1 500 $, et le support client environ 5 000 $. Cette liste concerne plusieurs services. [2]
On ne peut donc pas écrire : « Photo AI fait maintenant 105 000 $ de bénéfice par mois ». Les mois diffèrent, la portée de l’activité diffère, et on ne sait pas non plus comment les heures de maintenance futures sont calculées. Économiser sur les frais fournisseurs ne signifie pas non plus augmenter les revenus des nouveaux clients.
Deux : je m’intéresse davantage à savoir où l’argent a déjà été dépensé avant que les remboursements ne surviennent.
Dans la FAQ du site de Photo AI, les critères de remboursement évaluent notamment si un modèle a déjà été créé, le nombre de générations effectuées, des liens de recommandation, etc. Une explication officielle est que l’amont ne remboursera pas les frais de traitement GPU déjà consommés. Ici, je ne fais que relayer les explications du site officiel en date du 17 septembre, sans juger de l’efficacité juridique ou contractuelle de ses modalités. [3]
Si un client n’est pas satisfait d’une photo, il peut demander une refaire ; mais le calcul de la première tentative ne s’annule pas automatiquement. Pour un exploitant, entre « une commande reçue » et « une commande livrée », il peut aussi s’intercaler des générations échouées, des échanges avec le support et des remboursements.
Cela me donne envie de noter cinq chiffres pour chaque commande : le montant effectivement encaissé, le nombre de générations réelles, le coût des retours en cas d’échec (retries), le montant des remboursements, et le nombre de minutes consacrées au support client. On ne comptabilise que les commandes livrées avec succès, ce qui permet de masquer les échecs les plus coûteux.
Le site officiel ne divulgue pas le taux de remboursement complet et ne précise pas non plus combien de tentatives en moyenne chaque client doit faire. Ces lacunes ne peuvent pas être remplacées par un taux de marge bénéficiaire qui semble très élevé.
Trois : on économise sur les abonnements logiciels, mais il faut aussi voir qui répare à minuit.
Le fait de construire des services de remplacement en interne constitue une méthode concrète de réduction des coûts. Mais la mise à niveau, les alertes, la compatibilité et la reprise après incident ne disparaissent pas avec les anciennes factures.
Si je devais essayer moi-même, je remplacerais d’abord une étape dont l’entrée/sortie est simple et pour laquelle, en cas de problème, on peut revenir à l’ancien plan. Je noterais séparément un mois de comptabilité : les nouveaux coûts, le nombre d’heures passées à déboguer, et le nombre d’interruptions. Une fois qu’il aura traversé de vrais incidents, je déciderai alors s’il vaut la peine d’étendre l’approche.
Sans historique de maintenance, le « montant économisé chaque mois » ne fait qu’indiquer un changement de facturation ; cela ne suffit pas à prouver que les personnes sont devenues plus légères.
Quatre : que peut apporter ce cas aux personnes qui évaluent des projets liés à l’IA ?
Pour étudier les revenus d’un produit, je continuerai à questionner le chemin de l’argent : qui paie, ce qui est acheté, à quelle fréquence on achète, et qui prend en charge les remboursements. S’il est aussi question d’un certain token, je vérifierai en plus s’il existe un mécanisme clair et exécutable de répartition des revenus. Si un produit est rentable, cela ne permet pas automatiquement de conclure que les détenteurs de tokens reçoivent des flux de trésorerie. Photo AI est ici un exemple d’activité logicielle ; cet article n’apporte pas la preuve que cela crée un lien de revenus avec un quelconque token.
Quand on étudie sa propre activité secondaire, la question devient encore plus directe : pour la prochaine commande, quels processus pourra-t-on réutiliser ? Est-ce qu’on continue à accepter les commandes les plus pénibles ? Si une personne s’absente quelques jours, pourra-t-on détecter et rétablir les tâches échouées ?
Je n’ai pas acheté ni testé Photo AI en conditions réelles. Les informations publiques ne donnent pas non plus un coût complet d’acquisition, le taux de rétention, ni le taux d’échec, ni le nombre d’heures de travail du fondateur. Ce cas mérite d’être étudié, mais il est encore insuffisant pour dresser une fiche de rentabilité destinée à ceux qui veulent le reproduire.
D’abord, noter précisément « combien par commande » et « combien de temps y est passé », puis discuter si cela peut devenir un actif de long terme.
Source des informations (vérifiée au 17 septembre 2026)
[1] Pieter Levels，2026-03-06：
https://levels.io/photoai-40870-line-index-php-105k-mo-revenue
[2] Pieter Levels，2026-09-09：
https://levels.io/replaced-saas-with-vibe-coded-services
[3] FAQ du site officiel de Photo AI :
https://photoai.com/
Analyse indépendante ci-dessus fondée sur des documents publics ; ce n’est ni une promesse de rendement, ni un conseil en matière de transaction. Les images servent à organiser des informations préparées avec l’aide de l’IA.