Quand des SDK optionnels se comportent comme de l’infrastructure cœur

Un mode de panne fréquent au lancement dans les apps mobiles vibe codées, c’est que l’analytics, l’attribution ou le crash reporting s’initialisent en même temps que les services vraiment critiques. Si l’un de ces SDK optionnels se comporte mal sur un appareil donné ou dans une condition réseau précise, l’app entière peut mourir avant même le premier écran.

Cela arrive parce que le code d’initialisation généré par IA tend à traiter chaque dépendance comme si elle avait la même importance. Sans système de niveaux explicite, il n’y a plus de distinction architecturale entre l’infrastructure indispensable et les observateurs nice-to-have. Tout devient indispensable par accident.

Trois niveaux de dépendances

Chaque dépendance de votre app entre dans l’une de ces trois catégories. Tracer ces lignes explicitement, c’est la différence entre une app qui survit à la croissance et une app qui meurt sous mille plantages de production :

  • Hard dependencies : si elles échouent, votre app ne peut pas rendre. Parsing de config. Création du stockage. Construction des services cœur. C’est votre fondation.
  • Soft dependencies : elles peuvent échouer proprement. Auth. Features dépendantes du réseau. Flows dépendants des permissions. Le shell de l’app continue à s’afficher ; l’utilisateur voit une expérience dégradée, pas un crash.
  • Optional dependencies : elles peuvent échouer en silence. Analytics. Crash reporting. A/B testing. Elles ne bloquent jamais l’app. Ce sont des observateurs, pas des participants.

L’erreur que font la plupart des apps vibe codées, c’est de tout traiter comme du hard. Chaque SDK est initialisé au démarrage. Chaque échec devient un crash de startup. Pourtant, votre SDK analytics ne mérite pas le même statut que votre couche de stockage.

La frontière des hard dependencies

La frontière hard valide la config et construit les services. Si elle échoue, l’app affiche un écran d’erreur avec un bouton de retry, pas un vide blanc que les utilisateurs vont sanctionner d’une étoile sur l’App Store.

// src/context/hard-dependency-boundary.tsx
// This is the gatekeeper. If it fails, nothing else renders.

import * as SplashScreen from 'expo-splash-screen'

void SplashScreen.preventAutoHideAsync()

export function HardDependencyBoundary({
  children,
}: {
  children: (services: Services) => ReactNode
}) {
  const { services, ready, error, retry } =
    useHardDependencies()

  useEffect(() => {
    if (ready || error) void SplashScreen.hideAsync()
  }, [ready, error])

  if (error) {
    return (
      <ErrorScreen
        title='Startup failed'
        message={error.message}
        onRetry={retry}
      />
    )
  }

  if (!ready || !services) return null

  return <>{children(services)}</>
}

Remarquez le pattern render prop. La boundary transmet les services initialisés à ses enfants. Les enfants ne construisent pas les services ; ils les reçoivent. La construction arrive exactement une fois, et tout échec est intercepté à la boundary, pas remonté dans un crash report de production.

La boundary optionnelle

Comparez maintenant avec les dépendances optionnelles. Elles ne doivent jamais faire planter votre app. Si Mixpanel tombe, votre app ne doit même pas tousser :

// src/context/optional-dependency-boundary.tsx
// If analytics fails, we log a warning and keep going.

export function OptionalDependencyBoundary({
  children,
}: PropsWithChildren) {
  const { analytics, crashReporting } = useServices()

  useEffect(() => {
    try {
      analytics.track('app_started')
    } catch (error) {
      if (__DEV__) console.warn('Analytics failed:', error)
    }

    try {
      crashReporting.setContext('app', { started: true })
    } catch (error) {
      if (__DEV__) console.warn('Crash reporting failed:', error)
    }
  }, [analytics, crashReporting])

  return <>{children}</>
}

La différence d’attitude saute aux yeux. Boundary hard : si elle échoue, on montre un écran d’erreur. Boundary optionnelle : si elle échoue, on logge un warning et on continue. Les deux sont explicites. Aucune ne prétend être l’autre.

La plupart des crashs de production dans les apps vibe codées viennent d’une seule erreur : traiter des dépendances soft ou optionnelles comme si elles étaient hard. L’Autotomy Expo Starter Pack trace ces lignes dès le premier jour pour que vous n’appreniez jamais cette leçon à 2 h du matin.