Портал gosuslugi.ru работает с 2009 года, и за это время граждане привыкли получать справки и записываться к врачу через браузер. Но точка доступа сместилась. По данным операторов, смартфоны уже составляют заметную долю продаж, а мобильный трафик растёт двузначными темпами каждый квартал. Ведомство, которое держит услуги только в вебе, теряет контакт с гражданином ровно в тот момент, когда тот стоит в очереди или едет в транспорте с телефоном в руке. Мобильное приложение – это не дубликат портала, а отдельный канал со своей логикой работы.
Что отличает мобильный канал от веба
Главная ошибка – перенести веб-форму в приложение один к одному. На экране 4 дюйма длинная анкета ЕПГУ нечитаема. Мобильный сценарий строится вокруг трёх-четырёх массовых операций: проверка штрафов ГИБДД, статус заявления, запись на приём, уведомления о готовности документа. Остальное оставляем порталу.
Технически мы видим два устойчивых подхода. Нативные приложения под iOS и Android дают доступ к камере, push-уведомлениям и геолокации – это критично для проверки документов и навигации к ведомству. Гибридные решения на HTML5 дешевле в поддержке, но проигрывают в отзывчивости. Для госуслуг с массовой аудиторией мы рекомендуем нативную разработку: разница в удержании пользователя окупает затраты.
Push-уведомления меняют саму модель взаимодействия. Вместо того чтобы гражданин раз в неделю заходил проверять статус, ведомство само сообщает: заявление принято, документ готов, назначен приём. Это снижает нагрузку на колл-центры и очное обслуживание.
Интеграция и безопасность
Приложение бесполезно без связи с инфраструктурой электронного правительства. Аутентификация идёт через ЕСИА, обмен данными между ведомствами – через СМЭВ. Это значит, что мобильный клиент работает поверх тех же сервисов, что и портал, и не хранит персональные данные на устройстве дольше сессии.
Здесь всплывает вопрос серверной части. Нагрузка мобильного канала пиковая и неравномерная: рассылка push-уведомлений по региону за минуту поднимает тысячи обращений к API. Бэкенд должен это выдерживать. Мы строим серверную часть на открытом стеке – подход, который мы разбирали в материале про переход госведомств на Linux и открытое ПО. Это снимает лицензионные ограничения на горизонтальное масштабирование. Если в основе лежит унаследованная проприетарная СУБД, её узкие места проявятся именно под мобильной нагрузкой – мы описывали типовой сценарий в статье про миграцию с проприетарных баз данных.
Безопасность мобильного клиента – отдельная дисциплина. Устройство теряют, его взламывают, по Wi-Fi в кафе перехватывают трафик. Минимальный набор: шифрование канала, отказ от хранения учётных данных, привязка сессии к устройству, защита от перехвата на скомпрометированном телефоне. Сертификация по требованиям регуляторов добавляет к проекту несколько месяцев – это надо закладывать в план с самого начала.
Сроки и эксплуатация
Запустить приложение – половина задачи. Дальше его сопровождают годами: новые версии ОС, изменения в регламентах услуг, обновления API портала. Без отлаженного процесса выкатки каждое обновление превращается в риск. Поэтому мобильную разработку мы ведём с короткими итерациями и автоматизированной сборкой – об этой инженерной культуре мы писали в материале про практики DevOps.
Реалистичный срок первой публичной версии с базовым набором функций – четыре-шесть месяцев, с учётом интеграции и сертификации. Попытка уложиться в два месяца обычно означает приложение без связи с реальными сервисами, то есть красивую витрину без пользы.
Вывод
Мобильное приложение госуслуг – это не маркетинговая галочка, а рабочий канал с собственной архитектурой, требованиями к безопасности и циклом сопровождения. Начинать стоит с двух-трёх массовых сценариев и устойчивого бэкенда, а не с полной копии портала. Путь от проектирования до публикации в сторах укладывается в нативную разработку под iOS и Android с интеграцией в инфраструктуру электронного правительства.
