--- title: "Charlie Tang Hoong — Forward Deployed AI & Automation Engineer, Malaisie" url: https://cv.tanghoong.com/fr/ locale: fr description: "Ingénieur IA appliquée et automatisation forward deployed à Selangor, en Malaisie. Plus de 15 ans à transformer des problèmes métier flous en systèmes d’IA, d’automatisation et de logiciel en production, en Malaisie, à Singapour et en Asie-Pacifique." --- # Charlie Tang Hoong **Forward Deployed AI & Automation Engineer** — Selangor, Malaisie · UTC+8 Je transforme des problèmes métier flous en systèmes d’IA, d’automatisation et de logiciel opérationnels. Quinze ans, depuis Selangor en Malaisie — et l’essentiel de ce travail commence de la même façon : un système construit par quelqu’un d’autre, sans documentation, et une activité qui ne peut pas s’arrêter pendant qu’on le répare. ## Preuves - **2 sur 3 déconseillés** — Études de faisabilité IA dans trois domaines sans lien. J’en ai déconseillé deux sur le coût d’investissement ; la troisième a été construite. - **Des milliards d’impressions** — Chaque mois, sur la plateforme AdTech où j’ai travaillé — des dizaines de milliers de requêtes par seconde, et un p95 sous 100 ms sur les chemins backend que j’ai reconstruits. - **15+ pipelines** — Veille tarifaire, génération de prospects et veille de marché — pour des PME qui avaient besoin qu’on surveille une liste de prix, ⛔ pas qu’on construise une plateforme. - **15+ ans** — Quatre employeurs, un contrat à Singapour, deux entreprises à moi et des missions en indépendant — aussi bien des équipes d’exploitation grand compte que des PME de deux personnes. Deux de ces trois propositions d’IA n’ont pas été suivies, et c’est précisément l’intérêt : le client a eu un vrai chiffre assez tôt pour dire non sans que cela coûte cher. ## Travaux choisis Cinq missions choisies, écrites toutes de la même façon : ce que le client cherchait à faire, ce qui n’était pas clair, ce que j’ai décidé, ce que j’ai construit ou conseillé, et le résultat qui a suivi. - Cas 1 — Construire sur un système qui n’était pas le nôtre: Une plateforme de réservation et de commande à plusieurs rôles est passée en production sur l’ERP hérité d’un client grand compte, avec le contrat d’API négocié directement avec les ingénieurs du client et chaque changement de périmètre validé par écrit avant d’arriver au développement. - Cas 2 — Retirer la saisie d’un flux documentaire qui ne pouvait pas s’arrêter: Un pipeline hybride OCR et LLM a nettement réduit la saisie manuelle dans un flux de documents maritimes à fort volume, au sein d’une exploitation dont les systèmes sources n’avaient pas d’API et ne pouvaient pas être remplacés. - Cas 3 — Servir le trafic d’un assistant IA sans garder une connexion ouverte: J’ai repensé le chemin de requête d’un assistant de support client IA pour qu’une conversation soit mise en file et interrogée par sondage plutôt que maintenue sur une connexion synchrone — livré et intégré. - Cas 4 — Trois propositions d’IA, et les deux que j’ai déconseillées: Trois missions de faisabilité IA dans trois domaines sans lien, chacune transformée en une conception de solution avec un chiffrage : deux ont été refusées à juste titre sur le coût d’investissement, et la troisième a été construite. - Cas 5 — Le socle technique : des milliards d’impressions et une place de marché autonome: Onze ans en deux passages dans la même société d’AdTech : quatre ans comme seul ingénieur frontend sur une conversion de plateforme, puis une place de marché publicitaire en libre-service construite de bout en bout, puis des services backend portant des dizaines de milliers de requêtes par seconde. ## Ma façon de travailler Les mêmes sept étapes, que le client soit une équipe d’exploitation grand compte ou une PME de deux personnes. L’ordre compte plus que les outils : presque tous les échecs de livraison que j’ai vus étaient joués avant qu’une ligne de code soit écrite. - **01 Découvrir** — M’asseoir avec ceux qui font le travail aujourd’hui et documenter le processus tel qu’il tourne vraiment, ⛔ pas tel que l’organigramme le décrit. L’essentiel de ce qui compte n’est pas dans le brief. - **02 Définir** — Dessiner le flux proposé, le dérouler avec la partie prenante, et obtenir une confirmation écrite avant que le développement commence. Nommer ce qui est explicitement hors périmètre, et ce qui est volontairement reporté à une deuxième phase. - **03 Concevoir** — Décider quoi acheter et quoi construire avant de décider comment le construire. Intégrer les briques devenues des produits, construire à la main le chemin critique, et être honnête sur les contraintes qui sont réelles — connectivité, droits, cycle de livraison de quelqu’un d’autre, un budget qui ne bougera pas. - **04 Construire** — Prendre en charge moi-même le travail complexe qui définit le contrat ; déléguer la surface simple. Quand une tâche reste sans direction claire après trente minutes, elle devient une discussion de conception, ⛔ pas une reprise silencieuse. - **05 Déployer** — Partir du principe que l’environnement n’est pas le mien à changer. Intégrer sans envahir : lire depuis ce qui existe déjà, poser des points de reprise sur les traitements longs pour qu’une interruption reprenne au lieu de repartir de zéro, et toujours laisser un chemin pour qu’une personne reprenne en cours de route. - **06 Mesurer** — Décider dès le départ ce que « ça marche » veut dire et comment on l’observera — comportement des reprises, visibilité des pannes, coût par requête, et pour un système d’IA un jeu d’évaluation plutôt qu’une impression. - **07 Itérer** — Livrer la phase, garder visibles les prérequis de la deuxième, et laisser ce que la production révèle réordonner la liste. ## Ce que j’apporte - **Recueil du besoin et cadrage de solution** — Travailler directement avec ceux à qui le problème appartient — personnel d’exploitation, fondateurs, les ingénieurs du client eux-mêmes — pour transformer un brief incomplet en un périmètre défini, avec un chiffrage et une définition du « terminé » convenue. Je l’ai fait des deux côtés : comme spécialiste interne des processus cartographiant des flux financiers et logistiques non documentés, et comme ingénieur extérieur cadrant des projets d’IA pour des PME qui n’en avaient jamais acheté. - **IA appliquée et automatisation des flux** — Des systèmes d’IA qui doivent tourner dans une exploitation réelle : extraction documentaire avec une étape de relecture humaine avant tout enregistrement, assistants de support client avec structure des connaissances, intégration d’outils, gestion des sessions et escalade vers une personne, et des flux RPA sur des tâches financières et logistiques autrefois saisies à la main. - **Architecture de solution et intégration en entreprise** — Relier des systèmes qui n’ont jamais été conçus pour être reliés — l’ERP hérité d’un client, des systèmes sources sans aucune API, des plateformes de commerce et de paiement tierces, des files de messages, et les étapes manuelles entre les deux. La décision récurrente est acheter ou construire, et j’ai été des deux côtés assez souvent pour savoir que la question intéressante est : quelle contrainte fait échouer la brique achetée ? - **Ingénierie de production et fiabilité** — Assumer un système après sa mise en service. Des traitements longs qui reprennent où ils se sont arrêtés plutôt que de repartir de zéro. Des pannes qui apparaissent à une heure où une personne peut encore revenir au processus manuel. Un traitement par files pour qu’une requête lente ne bloque pas le client suivant. Des envois qu’un rafraîchissement de page ne peut pas déclencher deux fois. De la capacité inutilisée qui est rendue plutôt que retenue. - **Conduite technique et alignement des parties prenantes** — J’ai mené la livraison et les décisions techniques, ⛔ pas des effectifs : l’arbitrage final d’architecture et de choix technologiques après avoir écouté l’équipe, la pratique de relecture de code sur laquelle une équipe s’aligne, et l’accompagnement des développeurs jusqu’à ce qui les bloque réellement — c’est-à-dire, d’expérience, presque toujours le contrat d’API et non le code.